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ABSTRACT 


SID  (System  for  Incremental  Development)  is  a computer  system  for  Incrementally 
designing  and  verifying  targe,  complex  programs.  It  executes  commands,  proposes  actions, 
answers  questicms,  and  accepts  and  reasons  about  new  or  changed  information. 

SID  has  three  main,  distinctive  characteristics.  First,  it  provides  several  useful 
incremental  capabilities,  including  the  ability  to  respond  to  changes  by  ensuring  that  the  final 
problem  solution  is  consistent  and  by  keeping  intact  still-valid  work  without  complete 
reprocessing.  Second,  its  user  interface  has  the  ability  to  guide  the  user  through  the  design  and 
verification  and  to  engage  In  an  interactive  English  dialog  about  the  potential  effects  of 
changes.  It  not  only  previews  these  effects,  but  also  explains  the  reasons  for  them.  Third,  it 
supports  a substantial  programming  language,  which  includes  features  for  generating  run-time 
checks,  stating  concurrent  processes  and  shared  data,  and  developing  data  abstractions. 
Complete  type  checking  is  performed  on  programs,  specifications,  and  assumed  properties. 

The  system  responds  to  changes  by  applying  a new  methodology  that,  although 
couched  here  In  the  domain  of  design  and  verification,  may  also  be  useful  in  other  areas  in 
which  incremental  reaction  to  change  is  important.  Parts  of  a general  framework  for  designing 
incremental  systems  are  proposed. 

SID  has  been  used  to  completely  design  and  verify  several  programs,  including  a 
simple  message  switching  network  that  allows  secure,  asynchronous  message  transfer  among  a 
flx^  number  of  users. 
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CHAPTER  1 


INTRODUCTION 


1.1  Incremental  Program  Dcgign  and  Verification 

When  designing  and  verifying  programs,  a series  of  steps  Is  performed  In  which  the 
data  Is  not  only  repeatedly  added  to,  but  also  often  revised  due  to  conceptual  reformulation  or 
error  correction.  This  evolutionary,  or  Incremental,  process  entails  using  knowledge  of  design 
and  verification  and  of  the  context  of  revisions.  To  effectively  support  this  kind  of  activity 
with  a computer,  a program  with  a highly  integrated,  Incremental  view  of  design  and 
verification  Is  needed. 

The  objective  of  this  research  Is  to  provide  such  a system  for  Incrementally  designing 
and  verifying  programs  of  significant  size  and  complexity.  Consequently,  three  main  system 
design  goals  emerged.  The  system  should: 

• Provide  useful  incremental  capabilities.  7'his  Includes  the  ability  to  respond 
Co  changes  by  ensuring  that  the  final  problem  solution  is  consistent  and  by 
keeping  intact  still-valid  work  without  complete  reprocessing. 

• Provide  a good  user  Interface.  This  Includes  the  ability  to  guide  the  user 
through  the  design  and  verification  and  to  answer  questions  about  it 

• Support  a subst:>ntial  programming  language.  Desirable  language  features 
include  extensive  programming  and  specification  facilities,  verifiability,  and 
constructs  for  assisting  in  incremental  development. 


This  report  reproduces  a thesis  of  the  same  title  submitted  to  the  Departntent  of 
Computer  Sciences  at  The  University  of  Texas  at  Austin  on  6 December  1977  in  partial 
fulfillment  of  the  requirements  for  the  degree  of  Doctor  of  Philosophy. 

Author’s  current  address:  Computer  Science  Laboratory,  Stanford  Research  Institute, 
Menlo  Park,  California  94025 
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This  dissertation  describes  a working  prototype  system  - called  SID  (System  for 
Incicmental  Development)  --  that  realizes  these  goals.  It  is  capable  of  accepting  and  reasoning 
about  new  or  changed  information,  of  carrying  out  manipulations  that  are  too  complex, 
cumbersome,  and  tedious  to  do  reliably  by  hand,  of  dynamically  proposing  actions  to  the  user, 
and  of  engaging  in  an  English  dialog  about  the  task.  It  allows  the  user  to  design  his  program 
by  any  of  several  strategies,  verify  it  in  parallel  or  any  desired  order,  and  make  changes 
whenever  convenient. 

SID  supports  the  language  Gypsy  [Ambler,  et  al.  77],  whose  consistent  integration  of 
both  programming  and  specification  statements  allows  the  system,  among  other  things,  to  type 
check  programs,  specifications,  and  assumed  properties.  Gypsy  Includes  features  for  writing 
several  forms  of  specifications,  generating  run-time  checks,  stating  concurrent  processes  and 
shared  data,  handling  errors,  developing  data  abstractions,  and  assisting  in  program 
development. 

SID  responds  to  changes  by  applying  a new  methodology  that,  although  couched  here 
in  the  context  of  design  and  verification,  may  also  be  useful  in  other  areas  in  which 
Incremental  reaction  to  change  is  Important.  Consider,  for  example,  the  development  of  new 
mathematical  theories.  It  is  commonplace  to  introduce  lemmas  or  definitions,  revise  them  (or 
previous  ones)  for  any  of  several  reasons,  then  try  proofs  again.  As  a practical  matter,  these 
changes  should  be  compensated  for  without  completely  redoing  previous  work  that  remains 
valid. 


The  organization  of  this  dissertation  Is  as  follows.  Section  1.2  presents  a detailed 
sample  session  which  illustrates  the  functioning  of  the  system,  with  emphasis  on  features  that 
enhance  incremental  development.  The  example  developed  is  referred  to  in  later  chapters. 

Chapter  2 compares  SID  with  several  other  program  verification  systems.  Differences 
In  philosophy,  capabilities,  and  achievements  are  described. 

Chapter  3 describes  the  system  - its  design,  user  interface,  incremental  capabilities, 
and  functional  components.  A multi-level  overview  of  the  design  is  given  and  the  Impact  of 
the  Incremental  approach  is  studied.  The  user  interface  is  described,  the  novelty  of  which  lies 
in  Its  dual-mode  philosophy,  giving  the  user  the  option  of  directing  the  system  by  giving 
commands,  or  being  guided  through  the  system  by  accepting  suggestions,  or  a combination  of 
both.  Suggestions  are  based  on  the  current  state  of  development.  Also  of  practical  importance 
is  its  ability  to  answer  "what"  and  "why"  questions  about  the  potential  effects  of  changes.  The 
Incremental  capabilities  of  the  system  are  Itemized,  accompanied  by  an  explanation  of  how 
those  that  are  not  covered  In  Chapter  4 are  accomplished.  Characteristics  of  each  functional 
component,  some  of  which  were  developed  by  others  specifically  for  this  system,  are  described 
and  illustrated.  Excerpts  from  the  scenario  of  Section  1.2  arc  used  In  explanations. 


Page  S 


Chapter  4 focuses  on  the  methodology  for  responding  to  changes  to  programs, 
specifications,  and  properties  assumed  in  proofs.  The  effects  of  changes  are  determined  by 
exploiting  useful  constraints  on  how  objects  in  the  domain  Interact  with  one  another.  For 
example,  previous  verification  work  is  kept  Intact  by  employing  logical  rules  which  describe 
when  changes  to  specifications  have  no  effect. 

Practical  considerations  significantly  influenced  the  design  of  the  methodology.  For 
example,  the  methodology  allows  temporary  inconsistencies  (such  as  references  to  programs  to 
be  defined  later),  applies  to  any  of  several  design  and  verification  strategies,  and  adapts  to  a 
class  of  Pascal-like  languages  and  their  related  proof  methods.  The  description  of  the 
methodology  given  in  Chapter  4 is  intended  to  be  formal  enough  to  allow  Implementations  to 
be  direct,  while  suppressing  unimportant  details. 

Chapter  5 studies  the  problem  of  designing  other  incremental  systems.  Key  issues, 
practical  tradeoffs,  and  some  problems  are  discussed.  A general  framework  is  proposed  for 
answering  some  of  the  questions  raised.  Other  questions  are  explored  by  means  of  illustrative 
examples. 


1.2  Kxamplc  Session 

This  section  contains  an  example  session  with  SID  In  which  a sorting  program  is 
Incrementally  designed  and  verified  using  a top-down  strategy.  This  session  Illustrates  some 
ways  In  which  SID  executes  user  commands,  proposes  actions,  answers  questions  about  aspects 
of  the  design  and  verification,  and  accepts  and  reasons  about  new  or  changed  Information 
throughout  the  development. 

In  addition  to  this  sorting  example,  a message  switching  network  that  allows  secure, 
asynchronous  message  transfer  among  a fixed  number  of  users  is  developed  in  Appendix  A. 
1 he  network,  being  larger  and  more  complex,  underscores  the  Jmportance  of  the  system’s 
incremental  philosophy.  Some  of  the  interesting  features  of  the  network  are  concurrency,  data 
abstraction,  and  error  handling. 

I'he  session  given  below  Is  an  abstracted  version  of  an  actual  session  that  is  intended 
to  convey  a representative  sample  of  SID’s  Incremental  capabilities.  The  sorting  program 
developed  consists  of  three  executable  programs  (Exchange—sort  being  the  top-level  program 
which  invokes  Location_of_max  and  Exchange)  and  their  accompanying  data  declarations  and 
specifications.  The  scenario  shown  has  several  key  stages. 

I.  initial  design.  Exchange-sort,  which  is  only  partially  defined  and 
contains  unresolved  external  references,  is  entered  into  the  system.  When 
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attempting  to  generate  verification  conditions  (abbreviated  as  VCs),  the 
system  figures  out  that  the  operations  cannot  be  performed  due  to  constraints 
imposed  by  inconsistencies. 

2.  Removal  of  inconsistencies.  The  system  accepts  some  new 
information,  analyzing  it  within  and  incorporating  It  Into  the  existing 
context. 

3.  Verification.  Determining  that  VCs  can  now  be  generated,  SID 
generates  them  for  those  paths  in  Exchange_sort  that  are  completely  defined, 
and  temporarily  ignores  the  paths  that  are  not.  VCs  contain  only  references 
to  specifications  of  called  programs,  instead  of  the  specifications  themselves. 
Each  VC  is  then  proved,  expanding  complete  specifications,  or  parts  of 
specifications,  and  extending  the  collection  of  facts  known  to  the  system  as 
needed  during  proofs. 

4.  Continue  design.  The  user  and  system  engage  in  a conversation  in 
which  SID  previews  and  explains  the  potential  effects  of  intended  changes. 
Guided  by  this  interchange,  the  user  makes  several  changes  - the  definition 
of  Exchange_sort  is  completed,  previously-entered  information  is  changed 
(eg.,  some  Incomplete  specifications  are  extended),  new  information  is 
introduced  (eg.,  Location_of_max  and  Exchange  are  partially  defined).  The 
system  fits  all  these  changes  into  the  existing  problem  structure. 

5.  Continue  verification.  The  system  not  only  generates  the  new  VCs 
for  Fxchange_sort,  but  also  keeps  intact  its  still  valid  proofs.  Proof  of  the 
new  VCs  and  iterations  through  (4)  and  (5)  for  Locatlon_of_max  and 
Exchange  are  omitted. 

6.  Maintenance.  The  session  resumes  after  the  design  and  verification  is 
completed  to  demonstrate  the  utility  of  SID’s  explanation  facility  as  a 
maintenance  tool.  An  illustrative  dialog  explores  the  effects  of  a varied 
sample  of  possible  revisions  and  how  the  system  would  react  to  them. 


It  should  be  emphasized  that  the  purpose  of  this  example  is  not  to  convey  specific 
details  of  the  sorting  program  being  developed,  but  rather  to  illustrate  the  kinds  of  things  SID 
does  to  enhance  Incremental  design  and  verification.  The  reader  is  encouraged  to  at  least 
browse  through  the  entire  example  to  get  an  understanding  of  the  overall  scenario.  The  dialog 
at  the  end  of  the  session  Is  particularly  important  in  that  It  provides  a brief  capsule  of  SID’s 
effectiveness  in  handling  changes. 


Below,  lines  typed  by  a person  are  underlined  to  distinguish  them  from  the 
computer’s  response.  I'he  text  is  taken  verbatim  from  the  actual  session,  and  is  all  inclusive 
except  where  expllcitely  marked,  italicized  lines  are  comments  describing  some  of  the  features 
being  exhibited. 


Exac->  T 

Commands  arc:  Add,  Deteto,  EOit,  EXplain,  Help,  PRInt,  PROve, 
Restore,  SAve,  SUggest,  Translate,  Vcs,  tE,  7,  77. 

Exec->  T 

Enter  file  nome->  File I. Sri 


Typing  a carriage  return  before  completing  a multi-word  command  causes  the 
system  to  prompt  for  remaining  parts.  The  design  and  verification  begins  by 
reading  the  file  FileLSrt  into  the  system.  The  file  contains  programs  and 
sped  fications  which  are  echoed  by  the  system  as  they  are  read. 

const  n:int  ■ pending; 

lype  int_array  ■ array  ([  1 ..n])  of  int; 

function  Exchango_aort(A:int_array):int_array  > 
begin 

entry  N ge  1; 
exii  (all  hint, 

lin[I..N]->  Exchange_sort(A)[l] 

* Value_of_max(Exchange_sort(A),l ,1)) 
and  lsPerm(A,  Exchango_sort(A)); 

var  Btini array  :■  A; 

var  Krint  :=  N; 
keep  Kin[I..N]; 
loop 

assert  (all  hint,  I in  [k*l..N]  ->  B[l]  > Value_of_max(B,l,l)) 
artd  K in  [ 1 ..N]  and  lsPerm(A,B); 
if  K B I then  leave 
else  pending  end; 
end; 

result  :■  B; 
ertd; 
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No  syntax  arrors  dataclad. 

Semantic  errors  detected: 

function  EXCHANGE_SORT(A  : •NT_ARRAY) : INT_ARRAY  « 
begin 

entry  N go  1 ; 

exit  (all  I : (NT,  lin[l..N] 

->  EXCHANGE_SORT(A)[l] 

= VALUE_OF_MAX(EXCHANGE_SORT(A],  1, 1]) 
TPl 

and  ISPERM(A,  EXCHANGE_S0RT(A1]; 
tPl 


end; 

PI ! NAME  NOT  DECLARED 

Tfiis  specifies  and  partially  defines  the  sorting  program  ExcHang«_jort.  Its 
exit  assertion  states  that  the  output  array  is  sorted  into  ascending  order  and 
consists  of  all  the  elements  of  the  input  array,  and  nothing  else.  The  keep 
assertion  states  that  the  array  index  K is  always  within  range.  The  "pending” 
is  used  to  postpone  parts  of  the  implementation.  Semantic  errors,  detected  in 
both  specifications  and  executable  code,  are  due  to  unresolved  external 
references.  Although  incomplete  and  semantically  incorrect.  Exchange-sort  is 
stored  for  later  use. 

Exoc->  VCS  Exchange— sort 

**««  The  operation  VCS  is  not  legitimate  because  EXCHANGE_SORT  is  semantically 
incorrect. 

Knowledge  of  specific  tasks  is  used  to  determine  if  a particular  operation  can 
be  performed,  temporarily  cannot  be  performed,  or  cannot  ever  be  performed. 

Exoc->  Print  Status  All 

The  current  design  and  verification  status  is: 

Waiting  for  VC  generation  (semantics  must  be  corrected):  EXCHANGE_SORT 
Constants/Types:  INT_ARRAY,  N 
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Status  summaries  reflecting  the  current  state  of  development  aid  in  keeping 
track  of  progress  and  context.  This  summary  of  the  initial  design  indicates 
that  semantic  errors  in  Exchangesort  must  be  corrected  before  generating  its 
yCs,  and  that  Intuirray  and  N are  data  declarations.  The  user  proceeds  to 
correct  these  errors  by  changing  the  present  design. 

EK«e->  Edit 

A standard  text  editor  is  used  for  creating  and  changing  programs  and 
specifications.  The  user  leaves  the  system,  performs  the  desired  editing,  then 
returns  to  the  system  in  the  same  state  in  which  he  left  it. 

Ex«c->  Tr«ntl»t«  FIU2.Srt 

function  V«loo_of_m«{A:int_irr«y;  l,J:int):int  « begin  end; 

function  l»Porm(X,Y:int_jerrey)  : boolean  » 
begin 

exit  (assume 

(all  Z:int_array,  lsParm(Z,2))); 

end; 

All  data  entering  the  system,  whether  new  or  changed,  is  analyzed  within  the 
current  context,  then  fit  into  it  forming  a new  problem  state.  For  example, 
SID  uses  the  previously-defined  type  tnt-array  in  type  checking 
Value^of-max  and  IsPerm.  Both  of  these  new  functions  have  null  bodies  (as 
opposed  to  pending  ones),  indicating  that  they  are  solely  for  specification 
purposes  and  will  not  be  implemented. 

No  syntax  errors  detected. 

No  semantic  errors  detected. 

Exec->  Print  Status  All 

The  current  design  and  verification  status  is: 

Waiting  for  VC  generation  (must  check  semantics):  EXCHANGE^SORT 
For  specifications  only:  ISPERM,  VALUE_OF_MAX 
Constants/Types:  INT_ARRAY,  N 

The  system  knows  that  semantic  errors  previously  detected  in  Exchangesort 
may  now  be  corrected.  It  indicates  this  by  changing  "semantics  must  be 
corrected"  in  the  previous  status  summary  to  "must  check  semantics"  in  this 
one. 
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Ek«c->  VCS  EKch«nE«_jtort 

The  system  determines  that  this  command  can  now  be  carried  oui  and  displays 
both  program  paths  and  their  accompanying  verl  flcatlon  conditions. 

G«n«ratinK  VCc  for  FUNCTION  EXCHANGE.SORT 

Found  1-ST  path 
Found  2-ND  path 
Found  3-RD  path 
t pending  path  encountered. 


Beginning  new  path... 

B A 
K N 

Assume  (unit  entry  condition) 

N ge  I 

Continuing  in  path... 

Assume  (KEEP  assertion) 

K in  [I  ..N] 

Entering  loop... 

Evaluating  VALUE_OF_MAX(B,  I , I«1 ) 

Entry  assertions  of  programs  called  from  executable  code  or  specifications  are 
proved  at  all  calling  sites.  The  system  evaluates  the  entry  assertion  of 
Value,  of ^max  on  the  arguments  shown.  The  resulting  VC  is  automatically 
reduced  to  true  and  is  therefore  suppressed.  Had  it  not  redxued  to  true,  a VC 
would  have  been  spawned. 


Continuing  in  path. . 


Evaluating  tSPERM(A,  B) 
Continuing  in  path... 
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ASSERT  (alllaltlNT,  I«1  in  [K*I..N] 

->  B[l«l)  . VALUE_OF_MAX{B,  I,  \»l)) 

and  K in  [I  ..N] 
and  ISPERM(A,  B) 


Must  verify  ASSERT  condition 
Verification  condition  EXCHANGE_S0RT*1 
HI:  Me  N 
— > 

Cl:  ISPERM(A,  A) 

Notice  that  IsPerm  is  referenced  but  that  specifications  from  IsPertn  were  not 
added  to  the  hypothesis.  Instead,  such  specifications  are  added  completely  or 
partially  when  needed  during  proofs.  This  policy,  together  with  the  one  of 
simplifying  during  generation,  limits  the  size  of  PCs. 


End  of  path 


Beginning  new  path... 
Continuing  in  LOOP  ... 


Assume  (from  last  assertion) 

(alll«l:INT,  1*1  in  [K*  I . N] 

->  Btlol]  ■ VALUE_OF_MAX(B,  I,  I*!)) 

and  K in  [ I ..N] 
and  ISPERM(A,  B) 

Assume  (KEEP  assertion) 

K in  [I  N] 

Assume  (IF  test  failed) 

(not  K-1) 

Entering  PENDING  statement...cannol  continue  in  this  path 


End  of  path 


BeKinning  MW  path... 


End  of  path 


E*«e->  Print  Statua  t 

Viing  In  a command  (i.e.,  typing  the  escape  key)  Is  a way  of  having  the 
system  make  default  assignments.  The  assigned  value  here  is  Exchangesort. 

Waiting  for  ponding  path  to  bo  filled  in. 

EXCHANGE_SORTa|  . . . EXCHANGE_S0RTa3  waiting  to  be  proved. 

Presently,  Exchange^ort  contains  a pending  path  that  eventually  must  be 
implemented  and  has  three  ^Cs  that  must  be  proved. 

Emoc->  Suatost 

Rather  than  continuing  to  direct  the  system  by  giving  commands,  the  user 
wants  SID  to  propose  actions  needed  to  obtain  a problem  solution.  Acceptance 
of  a suggested  action  is  indicated  by  typing  "I". 

Suggest  proving  VC  called  EXCHANGE_SORTal->  | 

Entering  Prover  with  verification  condition  EXCHANGE_SORTel 
Hit  I le  N 
— > 

Cl:  ISPERM(A,  A) 


Prover->  Ute  ItPerm 

i 

. j 

EXCHANGE_SORTe]  proved  in  theorem  prover. 
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Proofs  are  omitted  for  brevity;  only  interactive  proof  steps  which  bring 
additional  knowledge  to  bear  on  the  deduction  are  shown.  The  command  Use 
IsPerm  adds  the  entire  exit  assertion  of  IsPerm  to  the  current  hypothesis. 

SuggMl  proving  VC  callod  eXCHANGE_S0RT«2->  Print  S1atu«  Exch«neo— «od 

Instead  of  accepting  a suggestion,  the  user  can  issue  a command.  If  command 
execution  causes  a state  change,  the  user  is  returned  to  command  mode  under 
the  assumption  that  he  wants  to  pursue  a line  of  reasoning  different  from  the 
scenario  now  modelled  internally.  For  commands  that  do  not  change  state  (e.g., 
print  commands),  the  same  suggestion  is  repeated  after  executing  the 
command. 

Waiting  for  ponding  path  to  bo  fillod  in. 

Waiting  to  bo  provod:  EXCHANGE_S0RT«2,  EXCHANGE_S0RT«3 

Provod  in  thoorom  provor:  EXCHANGE_S0RT*1 

Soggost  proving  VC  callod  EXCHANGE_S0RTa2->  I 

Entoring  Provor  with  vorification  condition  EXCHANGE_SORTo2 
HI:  all  I*!  : INT,  NI  in  [K*! ..N]  ->  VALUE_OF_MAX(B,  1,  I*!)  • B[l«ll 
H2:  Ksl 

H3:  ISPERMtA,  B) 

H4:  K in  [I..N] 

— > 

Cl:  I lo  N 


EXCHANGE_SORTo2  provod  in  thoorom  provor. 

Suggost  proving  VC  callod  EXCHANGE_S0RTo3->  | 

Entoring  Provor  with  vorification  condition  EXCHANGE_SORTo3 
HI:  all  lo|  : INT,  I*!  In  tKO  .N]  ->  VALUE_OF_MAX(B,  I,  lol)  - B[lo|] 
H2:  K^^l 

H3:  ISPERM(A,  B) 

H4:  K in  [I  . N] 

— > 

Cl:  all  I : INT,  I in  [I.N]  ->  VALUE_OF_MAX{B,  I,  I)  ■ B[l] 


r 
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Prov«f>  Use  Lemmi 
Enter  lemme  . . . 

* ell  Liinl.  ill  P;lnl Array. 

* L In  [I.  Nl  »>  Value_o(_  max(P.L.L)  r P(Ll: 

Lemma  added  ...  Its  name  is  LEMMAal 

New  lemmas  (and  also  rewrite  rules)  are  added  when  needed  during  proofs. 
They  are  parsed,  type  checked  within  the  context  of  the  overall  problem,  and 
named  for  subsequent  reference.  is  the  prompting  symbol  of  the 
translator. 


EXCHANGE S0RTa3  proved  in  theorem  prover. 

SuRRest  fully  defininR  EXCHANGE_SORT->  Print  Status  AH 

The  current  desiRn  and  verification  status  is: 

WaitinR  for  pendinR  path  to  be  filled  in:  EXCHANGE_SORT 
Proved:  EXCHANGE_SORT 
For  specifications  only:  ISPERM,  VALUE_OF_MAX 
Constants/Types:  INT_ARRAY,  N 

Since  all  TCs  for  Exchange^ort  are  proved,  the  user  now  is  ready  to  continue 
the  design.  But  before  actually  changing  the  present  design,  he  uses  SID  to 
explore  the  potential  effects  of  some  intended  changes. 

SuRRest  fully  defininR  EXCHANGE_SORT->  Explain 

j 

yVhat  are  the  effects  of  fully  defining  Exchange  sortT  j 

1 

EXCHANGE SORT  may  have  additional  VCs.  ! 


What  are  the  etfects  of  changing  the  exit  assertion  of  Value  of  maxT 


^ effects  on  VALUE — ^OF — MAX.  The  verification  ot  other  proRrams  It  not  attested. 
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<-  Why 


The  system  remembers  immediately  preceeding  sentences  to  answer  questions 
like  this  one. 

No  •ffocU  on  VALUE_OF_MAX  because  it  is  for  specifications  only  and  does  not 
have  VCs.  No  external  effects  because  properties  from  VALUE_OF^AX  have  not  been 
used  in  proving  any  VCs. 


What  are  the  effects  of  changing  the  exit  of  IsPerm? 

No  effects  on  ISPERM.  The  verification  of  other  programs  is  not  affected  if  the 
formula 

Changed  exit  specification 
— > 

Cl:  all  Z : INT_ARRAY,  ISPERM(Z,  Z) 
is  true.  If  not,  the  change  invalidates  the  verification  of  EXCHANGE_SORT. 

<-  Why? 


No  effects  on  ISPERM  because  it  is  for  specifications  only  and  does  not  have 
VCs.  Invalid  verification  because  properties  from  ISPERM  wore  used  in  proving 
EXCHANGE_SORTel, 


The  system  gives  a more  detailed  response  to  "why"  questions  than  to  "what" 
questions.  7 he  possible  effects  of  the  proposed  change  are  narrowed  down  to 
the  single  verification  condition  Exchange^ortel. 


<-  Done 

7 he  user,  knowing  the  potential  effects  of  these  changes,  is  now  ready  to 
continue  working  with  Sl[)  toward  a problem  solution. 

Suggest  fully  defining  EXCHANGE_SORT->  Edit 


Exec->  Translate  FileS.Srt 

function  Exchange_jiort(A:int_array):int_array 
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b«gin 

•ntry  N g*  I ; 
exit  (all  l:int, 

I in  [l.N)  ->  CKchanga_sorUA)[l] 

■ Valu«_of_max(Exchanga_sort(A),l  ,1)) 
and  lsP«rm(A,  Exchanga_jiort(A)); 
var  B:in(_array  :■  A; 
var  K:inl  :«  N; 

Keep  Kin[l..N]; 
loop 

assert  (all  l:inl,  I in  [K«1..N]  ->  B[l]  > Value_of_max(B,l,l)) 
and  K in  [1..N]  and  lsPerm(A,B); 
it  K E I ttien  leave  end; 

B Exchange(B,Localion_o(_max(B,l,K),K); 
k :=  K-1; 
end; 

result  B; 
end; 

function  Value_o(^max(A:int_array;  l,J:int):int  e 
begin 

exit  ( assume  ( all  K:int, 

k in  [I..J]  and  I in  [1  ..N]  and  J in  [I  ..N] 

->  A[k]  le  Value_of_max(A,l,J)  ) 
and  ( all  l,m:int, 

I in  [I..J]  and  m in  [I..J]  and  I in  [1..N]  and  J in  [1..N] 

->  Value_of_max(Exchange(A,l,m),l,J)  > 
Value_of_max(A,l,J)  ) ); 

end; 

(unction  Location_o(_max(A:int__array;  l,J:int):int  ■ 
begin 

entry  I in  [l.N]  and  J in  [I..N]  and  I le  J; 
exit  Location_o(_max(A,t,J)  in  [I..J] 
and  A[Location_o(_max(A,l,J)]  ■ Valua_ol_max(A,l,J); 
pending 
end; 

function  Exchango(A:int__array;  l,J:int):int_array  ■ 
begin 

entry  I in  [1  ..N]  and  J in  [I  ..N]; 
exit  (alt  k:[I..N], 

k ne  I and  k ne  J ->  Exchange(A,l,J)[k]  * A[k]  ) 
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and  lsExchanK«d(A,Exchanga(A,l,J),l,J) 
and  lsP«rm(A,ExchanKa(A,l,J)); 
pending 
•nd; 

function  lsExchanKod(A,B:int_array;  l,J:int):booloan  * 
begin 

exit  (assume  leExchanRed(A,B,i,i)  iff 

( lin[i..N]  and  Jin[l..N] 
and  A[I>:B[J]  and  A[J]>B[I]  ) ); 

end; 

function  lsPerm(X,V:int_array) : boolean  ■ 
begin 

exit  (assume 

(all  Z:int_array,  lsPerm(2,Z)) 
and  (all  Z:int_array, 

lBPerm(X,Z)  and  IsPermfZ.Y)  •>  lsPorm(X,Y))); 

end; 


No  syntax  errors  detected. 

No  semantic  errors  detected. 

Figuring  out  flow  to  fit  this  data  into  the  data  base  involves  observing 
relationships  that  have  disappeared,  observing  some  new  ones  that  are 
introduced,  and  using  deduction  to  decide  what  prior  relationships  still  hold. 

Exec“>  Print  Status  All 

The  current  design  and  verification  status  is: 

Waiting  for  VC  generation  (must  check  VCs):  EXCHANGE_SORT 
Waiting  for  pending  body  to  be  filled  in:  EXCHANGE,  LOCATION_OF^AX 
For  specifications  only:  ISEXCHANGED,  ISPERM,  VALUE_OF  JitAX 
Constants/Types:  INT_ARRAY,  N 

The  system  knows  that  the  set  of  verification  conditions  for  Exchange-sort 
may  now  be  changed.  This  is  reflected  by  the  phrase  "must  check  VCs"  in  the 
status  summary.  It  also  indicates  that  Exchange  and  Location-ofsnax  are 
partially  defined. 

Exec->  Suggest 


r 
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SuKKcst  gaoM’atinc  VCt  for  EXCHANGE_SORT->  f 

The  user  accepts  the  suggestion  to  continue  the  verification  of  Exchange^ort. 
Genoraling  n«w  verification  conditions  for  EXCHANGE_SORT  ... 


Beginning  new  path... 

Continuing  in  LOOP  ... 

Assumo  (from  last  assertion) 

(all  lot:  INI,  |a|  in  [K*1..N] 

->  B[l«l]  « VALUE_OF_MAX(B,  I,  H»l)) 

and  K in  [1  ..N] 
and  ISPERM(A,  B) 


End  of  path 


Unaffected  VCss  EXCHANGE_SORTal , EXCHANGE_S0RT«2,  EXCHANGE_SORTe3 

Only  new  paths  and  new  TCs  are  displayed,  while  previous  ones  that  are 
unaffected  by  changes  are  kept  intact.  Here,  additional  VCs  arise  because  the 
"pending"  in  F.xchange^sort  was  replaced  by  executable  code.  Determining 
that  TCs  are  unaffected  involves  logical  as  well  as  semantic  considerations. 

Suggest  proving  VC  called  EXCHANGE_S0RT«4->  Print  Status  All 

The  current  design  and  verification  status  is: 

Waiting  for  pending  body  to  be  filled  in:  EXCHANGE,  L0CATI0N_0F_MAX 
For  specifications  only:  ISEXCHANGED,  ISPERM,  VALUE_OF_MAX 
Constants/Types:  INT_ARRAY,  N 

EXCHANGE_SORT 

Waiting  to  be  proved;  EXCHANGE_S0RTe4,  EXCHANGE_S0RTa5, 

EXCHANGE__SORTaG,  EXCHANGE_S0RTa7 
Proved  in  theorem  prover:  EXCHANGE_SORTa  1 , EXCHANGE_S0RT«2, 

EXCHANGE_S0RTe3 
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SuKK«tl  proving  VC  called  EXCHANGE_SORra4->  | 


The  remaining  VCs  for  Exchange^ort  are  proved.  Then,  the  design  and 
verification  of  Locationuof-max  and  Exchange  is  continued,  following  a 
scenario  similar  to  the  one  shown  above  for  Exchange-sort.  A bug  is  detected 
in  Location-of -max  and  then  removed  by  paralleling  the  scenario  for  making 
any  other  kind  of  change.  The  session  is  repined  after  completing  these  tasks. 

Suggest  one  ol: 

<otc>  TRANSLATE  (from  file) 

SAVE  (problem  on  file) 

The  system,  knowing  that  the  problem  as  now  represented  is  solved,  presents  a 
menu  containing  two  reasonable  suggestions. 


->  Print  Status  All 


The  current  design  and  verification  status  is: 

Proved;  EXCHANGE,  EXCHANGE_SORT,  LOCATION_OF_MAX 
For  specifications  only:  ISEXCHANGED,  ISPERM,  VALUE_OF_MAX 
Constants/Types:  INT_ARRAY,  N 

This  summary  shows  that  the  design  and  verification  of  the  sorting  program  is 
complete. 


Suggest  one  of: 

<esc>  TRANSLATE  (from  file) 
SAVE  (problem  on  file) 

“>  Print  Onit  All 


Rather  than  accepting  a proposed  operation,  a display  of  all  program  units  in 
the  system  is  requested. 

const  N t INT  > PENDING; 

type  INT_ARRAY  • erray  ([I  ..N])  of  INT; 

function  EXCHANGE_$ORT(A  ; INT_ARRAY)  i INT_ARRAY  ■ 
begin 
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entry  N ge  1$ 

exit  (all  I : INT,  lin[l..N] 

->  EXCHANGE_SORT(A)[l] 

* VALUE_OF_MAX(EXCHANGE_SORT(A),  I,  I)) 
and  ISPERM(A,  EXCHANGE_SORT(A)){ 
var  B t INT_ARRAV  :«  A; 
var  K i INT  N; 

Keep  K in  [I  ..N]; 
loop 

assert  (all  |e|  : INT,  |el  in  [K*l  ..N] 

->  B[l«l]  . VALUE_OF_MAX(B,  I,  lal)) 

and  K in  [ 1 ..N] 
and  ISPERMCA,  B); 
if  K^l  then  leave  end; 

B EXCHANGE(B,  LOCATION_OF_MAX(B,  1,  K),  K); 

K :«  K-I 
end; 

RESULT  B 


T/ie  final  version  of  all  programs  and  specifications  are  printed  from  the 
system  data  base  in  an  easy-to-read  format  and,  for  this  command,  in  the 
order  in  which  they  were  originally  entered. 


Suggest  one  of: 

<esc>  TRANSLATE  (from  file) 
SAVE  (problent  on  file) 

->  Print  Lemma  AH 


LEMMAel  it 
all  L : INT, 

all  P ! INT_ARRAV,  L in  [l.N)  ->  VALUE_OF_MAX(P,  L,  L)  ■ PIL) 


LEMMAe4  it 
all  L,  M t INT, 
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■II  P > INT_ARRAY,  L in  [1  ..N]  and  M in  [1  ..N] 

->  ISPERM(P,  ALPHA(ALPHA(P,  L,  P[M]),  M,  PtL])) 

These  are  the  lemmas  used  In  (he  verification  of  (he  sorting  program. 

SuERest  on*  ol: 

<esc>  TRANSLATE  (from  fil*) 

SAVE  (problem  on  file) 

->  EitpUin 

The  explanation  facility  is  useful  not  only  during  a design  and  verification, 
but  also  afterwards  as  a maintenance  tool.  For  example,  it  may  be  desirable  or 
necessary  to  revise  an  incomplete  specification,  or  to  recode  on  individual 
program  for  efficiency.  Figuring  out  the  effects  of  such  changes  is  a 
formidable  task  even  for  this  small  example,  especially  after  a period  of  time 
has  elapsed.  The  following  dialog  emphasizes  its  utility  on  a varied  set  of 
questions. 

<“  What  ar*  Ih*  *ff*ctt  of  changing  Iha  header  of  IsParm? 


I 


PossibI*  offoett  of  changinR  th*  header  of  ISPERM  are: 

Incorrect  eemantice:  EXCHANGE,  EXCHANGE_SORT,  ISPERM,  LEMMA*4 
Invalid  verification:  EXCHANGE,  EXCHANGE_SORT 


<-  Why  it  Exchange  affected? 

Incorrect  semantics  because  EXCHANGE  calls  ISPERM.  Invalid  verification  because 
basis  property  LEMMAa4,  which  calls  ISPERM,  was  used  in  provinR  EXCHANGE*  1. 


<-  Why  is  E«chanEe_sorl  affected? 

Incorrect  semantics  because  EXCHANGE_SORT  calls  ISPERM.  Invalid  verification 
because  the  external  specifications  of  EXCHANGE,  which  call  ISPERM,  were  used  in 
provinR  EXCHANGE_S0RTa7.  Invalid  verification  because  the  external 
specifications  of  ISPERM,  which  recursively  call  ISPERM,  were  used  in  provinR 
EXCHANGE_SORTeI  and  EXCHANGE_S0RTa7. 


<-  What  are  the  effects  of  modifying  Lemmaa  I T 


g 


1 
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ChanRing  basis  property  LEMMA# I does  not  affect  the  verification  if 
Changed  lemma 

— > 

Cl:  all  L : INT, 

all  P : INT_ARRAY,  L in  [l.N]  ->  VALUE_0F_MAX(P,  L,  L)  « PtL] 
is  true.  If  nof,  the  change  invalidates  the  verification  of  EXCtfANGE_SORT  and 
LOCATION_OF_MAX. 


Because  it  was  used  in  the  proof  of  EXCHANGE_S0RT#3  and  L0CATI0N_0F_MAX«I. 

<-  Wh_aJ_are..the  effects  of  changing  the  exit  assertion  of  IsExchanged? 

No  effects  on  ISEXCHANGED.  The  verification  of  other  programs  is  not  affected  If 
the  formula 

Changed  exit  specification 

— > 

Cl:  ISEXCHANGEDIA,  B,  I,  J) 

iff  I In  [I ..NJ  and  J in  [l.N]  and  All]  - BIJ]  and  AtJ]  « B[l] 
is  true.  If  not,  the  change  invalidates  the  verification  of  EXCHANGE  and 
EXCHANGE_SORT. 


<-  Wh^r 

No  effects  on  ISEXCHANGED  because  it  is  for  specifications  only  and  does  not 
have  VCs.  Invalid  verification  because  properties  from  ISEXCHANGED  were  used  In 
proving  EXCHANGE# I and  EXCHANGE_S0RTe7. 


the  effects  of  changing  Ihe  entry  assertion  of  Location  of  m»»T 

Changing  the  entry  specification  of  L0CATI0N_0F_MAX  does  not  affect 

LOCATION — OF MAX  If  the  formula 

Changed  entry  specification 
— > 

Cl:  I in  [J..N] 

C2:  J in  [l  .N] 

C3:  I le  J 


and  the  formula 
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HI:  Mn  [I  .N] 

H2:  J in  [I..N] 

H3:  I Is  J 

— > 

Changed  entry  specification 

are  true.  If  not,  at  least  one  of  LOCATION_OF_MAX'8  VCs  is  incorrect.  The 
verification  of  other  programs  is  not  affected  if  the  second  formula  is  true.  If 
not,  at  least  one  VC  is  incorrect  for  EXCHANGE_SORT. 


<-  WhyT 


If  the  first  formula  is  false,  one  of  LOCATION_OF_MAX’s  VCs  is  changed.  If  the 
second  formula  is  false,  incorrect  VCs  because  the  entry  specification  of 
LOCATION_OF_MAX  is  proved  in  EXCHANGE_SORT  and  LOCATION_OF_MAX. 


<-  What  does  chanEine  its  exit  assertion  affect? 

"/f"  refer!  to  the  program  mentioned  in  the  last  "what"  question. 

Changing  the  exit  specification  of  LOCATION_OF.^MAX  does  not  affecf 
LOCATION„OF_MAX  if  the  formula 
HI:  LOCATION_OF_MAX(A,  I,  J)  in  [I..J] 

H2:  A[LOCATION_OF_MAX(A,  I,  J)]  « VALUE_OF_MAX(A,  I,  J) 

— > 

Changed  exit  specification 

is  true.  If  not,  some  of  LOCATION_OF_MAX’s  VCs  are  incorrect.  The  verification 
of  other  programs  is  not  affected  if  the  formula 
Changed  exit  specification 
— > 

Cl : LOCATION_OF_MAX{A,  I,  J)  in  [I..J] 

C2:  AlLOCATION_OF_MAX(A,  I,  J)]  « VALUE_OF__MAX(A,  I,  J) 
is  true.  If  not,  the  change  invalidates  the  verification  of  EXCHANGE_SORT. 


<-  Why? 

The  effecfs  on  LOCATION_OF_MAX  are  a change  in  its  VCs.  Invalid  verification 
because  properties  from  LOCATION_OF_MAX  were  used  in  proving  EXCHANGE — ^SORTaS 
and  EXCHANGE_S0RTa7. 
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<-  Dorw 


SugKast  on*  of: 

<esc>  TRANSLATE  (from  filo) 

SAVE  (problem  on  filo) 

->  Save 

Enter  file  name->  Sort.Dmp 

The  session  is  finished  and  the  current  problem  state  is  saved  on  file 
Sort.Dmp  in  a format  suitable  for  restoration. 


CHAPTER  2 


RELATED  RESEARCH 


This  chapter  presents  a general  review  of  six  previous  program  verification  systems, 
then  compares  them  to  SID.  Although  it  is  difficult  to  characterize  differences  between 
programs,  an  accurate  description  of  their  underlying  philosophy  and  their  capabilities  will  be 
attempted.  These  Impressions  have  not  been  reviewed  by  the  author(s)  of  the  systems  discussed 
herein. 


2.1  Program  Verification  Systems 

King  [69,71]  describes  the  Initial  program  verification  system.  It  is  essentially  written 
In  assembly  language,  being  the  only  non-Lisp-based  system  among  the  six.  This  system  is 
fully  automatic,  allowing  no  user  interaction  once  a program  and  its  specifications  are 
supplied.  King  [69,  p.  130,  p.  166]  points  out  that  the  inability  to  interact  with  the  user  is  a 
main  source  of  certain  system  limitations.  King’s  system  performs  extremely  well  on  the  small 
class  of  programs  to  which  it  applies,  including  certain  algebraic  computations,  such  as 
multiplication  (division)  by  successive  additions  (subtractions)  and  prime  determination,  and 
array  manipulations  like  zeroing  an  array  and  a simple  exchange  sort. 

Deutsch’s  system  [73]  has  successfully  verified  the  examples  In  King’s  thesis  (except 
the  system  of  linear  inequalities  in  Example  10)  , plus  various  other  programs  such  as  FIND 
[I  loare  71],  I'his  included  King’s  Example  9,  which  is  a sorting  program  King  was  unable  to 
verify  due  In  part  to  the  absence  of  a few  critical  assertions.  This  system  contains  a program 
editor,  allows  for  some  user  interaction,  and  has  in  part  a resolution-based  deductive  system. 
Deutsch  states  that  his  system’s  "major  departure  from  King's  system  arises  in  the  theorem 
generating  process"  [Deutsch  73,  p.  111-3].  King  utilizes  a backward  approach  to  VC 
generation  that  often  results  In  lengthy,  unmanageable  VCs.  Deutsch’s  system  generates  VCs 
in  a forward  manner,  very  similar  to  methods  originally  described  by  Good  [701  The  main 
idea  is  to  perform  certain  deductions  in  parallel  with  the  generation  to  produce  greatly 
simplified  VCs. 

The  SRI  system  [Elspas,  et  al.  73,  Waldingcr  and  Levitt  74]  differs  from  the  other 
systems  particularly  with  respect  to  their  deductive  system,  written  In  QA4  [Rulifson,  et  al.  721 
Since  QA4  incorporates  a considerable  variety  of  sophisticated  features  (e.g.,  pattern  matching 
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against  tuples,  bags,  and  s^ts,  backtracking,  goal-driven  deduction,  and  demons),  their  powerful 
theorem  prover,  which  uses  depth-first  search,  required  only  about  ten  pages  of  code  [Elspas,  et 
al.  73,  p.  43],  The  interactive  philosophy  of  this  system  is  that  the  user  gp'ants  permission  to 
allow  the  verifier  to  proceed;  it  has  been  used  to  verify  a varied  and  interesting  set  of  examples. 
This  set  includes  various  algebraic  computations,  array  sorting  and  rearrangement  programs, 
and  parts  of  a pattern  matcher  and  unification  algorithm. 

The  Stanford  University  system  fvon  Henke  and  Luckham  75,  Luckham  and  Suzuki 
75,  Suzuki  75]  has  verified  many  important  benchmark  programs,  including  several  sorting 
programs  (proving  termination  and  worst  case  timebounds  in  addition  to  the  standard  sorting 
properties),  programs  that  operate  on  pointers  [Luckham  and  Suzuki  76],  and  fairness  of  a 
simple  queuing  system  [Karp  and  Luckham  76].  The  VC  generator  is  that  of  Igarashl,  et 
al  [73].  The  system's  powerful  proving  facility  includes  an  arithmetic,  conditional,  and 
unconditional  simplifier,  a goal-subgoalcr,  plus  other  valuable  features  used  in  conjunction  with 
a resolution -based  theorem  prover.  User  Interaction  generally  occurs  only  when  the  user 
desires  to  add  certain  rules  or  strategies  applicable  to  the  domain  of  interest;  they  are 
subsequently  invoked  automatically. 

The  use  Information  Sciences  Institute/University  of  Texas  at  Austin  system  [Good, 
et  al.  75]  is  highly  interactive  and  has  verified  several  sorting  and  searching  programs,  small 
routines  from  the  verifier  and  from  a compiler  (all  converted  to  a subset  of  Pascal),  as  well  as 
examples  from  King's  thesis.  The  design  strategy  was  to  "provide  automatic  capability  for  the 
proof  process  where  possible,  and  to  rely  on  Interaction  for  manual  Intervention  otherwise" 
[Good,  et  al.  75,  p.  483].  The  authors  believe  the  main  unique  features  of  their  system  to  be 
"its  good  facilities  for  user  Interaction,  the  modular  system  design  which  uses  several  previously 
existing  components,  the  particular  natural  deduction  prover  that  Is  used,  and  the  theorem 
prover’s  method  of  Incremental  bounding  of  values  of  variables,  which,  among  other  things, 
facilitates  automatic  proof  by  cases"  [Good,  et  al.  75,  p.  483].  The  VC  generator  of  this  system 
is  essentially  the  one  of  Igarishi,  et  al.  [73],  originally  developed  at  Stanford;  and  Its  theorem 
prover  is  a variation  of  the  prover  discussed  in  Bledsoe  and  Bruell  [73],  originally  developed  at 
U'l'  Austin. 

Each  of  these  five  systems  can,  at  a first  approximation,  be  seen  to  consist  of  four 
main  components:  a parser,  VC  generator,  simplifier,  and  theorem  prover.  The  approach  to 
each  of  these  phases  of  verification  differs  somewhat  from  system  to  system,  as  does  the  amount 
of  user  interaction.  All  are  based  on  the  conventional  inductive  assertion  method,  and  all 
(excepting  King)  provide  facilities  for  handling  functional  abstraction. 

Another  notable  verification  system,  not  based  on  inductive  assertions,  is  the  Boyer- 
Moore  Lisp  proving  system  [Moore  73,  75,  Boyer  and  Moore  75,  77].  Based  on  structural 
induction,  it  uses  Lisp  for  stating  both  programs  and  specifications.  Its  proof  system  Includes 
heuristics  for  theorem  generalization,  rewrite  rules,  equality  substitution  rules,  and  a structural 
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Induction  heuristic.  Its  basic  strategy  is  to  EVAL  an  expression  via  the  Lisp  interpreter  and, 
if  it  is  not  T,  to  apply  parts  of  the  proof  system,  then  reiterate  the  process;  when  the  expression 
F.VAl.s  to  T,  the  proof  is  complete  It  has  automatically  proved  many  Interesting  Lisp 
properties  and  a simple  optimizing  compiler  for  expressions.  A typical  Lisp  property  proved  Is 
that  REVERSE  Is  Its  own  inverse,  i.e.,  that  (EQUAL  (REVERSE  (REVERSE  A))  A)  is 
1 RUE. 

Other  verification  systems  with  published  descriptions  include;  Carter,  et  al.  [77]  at 
IBM  T.  J.  Watson  Research  Center,  Crockert77]  and  Musser  [77]  at  USC  Information  Sciences 
Institute,  Mookway  [76,  Ernst  and  Uookway  75]  at  Case,  Marmier  [75]  at  ETH  In  Zurich, 
Schorre  [76]  at  SDC,  and  Topor  [75]  at  Edinburgh.  Also  of  interest  is  Good  [70],  which 
implemented  certain  useful  bookkeeping  facilities  as  part  of  a verification  system  that  accepted 
only  hand  proofs. 


2.2  Comparison  with  Previous  Systems 

Four  broad  areas  for  comparing  SID  with  other  systems  will  be  used.  Of  course,  no 
small  set  of  categories  can  completely  characterize  the  differences  between  programs,  but  they 
can  provide  some  viewpoints  to  help  see  past  superficial  differences. 

Toward  a New  Paradigm 

Paradigms  are  a good  way  of  looking  at  a class  of  Important  differences  between  SID 
and  earlier  systems.  In  the  past,  systems  for  assisting  in  producing  verified  programs  have 
been,  on  the  whole,  non  incremental  and  focused  on  verification  alone.  Looking  at  the  task  in 
this  way  imposes  several  sometimes  impractical  constraints  on  the  way  things  can  be  done.  To 
lift  these  constraints,  SID  appeals  to  a new  paradigm  - one  that  adopts  an  incremental, 
integrated  view  of  program  design  and  verification. 

It  is  easy  to  illustrate  the  inadequacy  of  the  non-lncremental  view.  Consider  a 
programming  problem  whose  solution  consists  of  several  programs  and  their  associated 
s|tccifications.  According  to  this  view,  all  programs  are,  in  essence,  completely  designed  and 
then  verified  separately  afterwards.  I'he  overall  verification  is  complete  when  all  individual 
ptograms  are  verified.  Or  is  it?  What  happens  If  modifications,  like  changing  a specification 
or  the  type  of  an  identifier,  were  made  along  the  way?  I'o  guarantee  consistency,  the  entire 
verification  must  be  re-started  from  the  beginning,  or  the  user  must  assume  the  burden  of 
determining  the  impact  of  changes,  or  a combination  of  both.  Most  often,  the  solution  is  the 
objectionable  activity  of  redoing  everything,  since  placing  the  burden  on  the  user  is  viable  only 
In  the  simplest  cases. 


Pape  26 


r 


What  additional  kinds  of  knowledge  does  SID  have  to  enable  It  to  lift  constraints 
Imposed  by  this  non-Incremental  view?  Previous  systems  are  knowledgeable  about  how  to  do 
iiidiviclual  verification  tasks,  such  as  how  to  generate  VCs.  But  they  are  not  knowledgeable 
enough  about  how  a verification  fits  together  (eg.,  what  specifications  are  In  what  VCs,  what 
properties  are  assumed  where,  what  functions  are  called  by  what  verification-related 
information),  how  a design  fits  together  (eg.,  dependencies  like  who  calls  whom,  or  where  Is  X 
assumed  to  be  of  type  Y),  and  how  design  and  verification  Interrelate.  SID  brings  together 
these  kinds  of  Issues. 


User  Interface 

Attention  to  user  Interface  issues  is  important  in  any  interactive  system  Intended  for 
actual  use.  The  degree  of  its  importance,  of  course,  varies  with  the  domain;  It  is  accentuated 
here  due  to  the  complexity  and  incremental  nature  of  the  task.  User/system  Interaction  may 
cKcur  often,  and  for  a wide  variety  of  reasons. 

How  does  SID  respond  to  such  issues?  Unlike  other  systems.  Its  command  structure  is 
ba.sed  on  a dual-mode  philosophy  that,  according  to  user  preference.  Is  active  In  helping  to 
figure  out  what  to  do  next,  or  is  passive  and  simply  responds  to  each  Input,  then  waits  for  the 
next.  Help  Is  provided  In  the  form  of  system-generated  suggestions,  which  are  always  based  on 
the  current  state  of  development.  Alternatively,  the  user  Is  given  the  option  of  directing  and 
querying  the  system  via  a comprehensive  set  of  available  commands. 

The  overall  effectiveness  of  Sip  is  also  significantly  enhanced  by  Its  ability  to  engage 
In  an  Interactive  English  dialog  about  the  potential  effects  of  changes,  as  shown  In  the  example 
session  of  Section  1.2. 


Programming  Languages  and  Proof  Methods 

Programming  languages  supported  by  earlier  systems  are  subsets  of  languages  such  as 
Pascal,  Algol,  or  Lisp. 

SID,  on  the  other  hand,  supports  the  language  Gypsy  which  has  three  Important 
features  that  these  other  languages  do  not  have.  The  first  Is  its  consistent  Integration  of 
program  and  specification  statements.  This  allows  SID  to  parse  and  type  check  programs, 
specifications,  and  properties  assumed  in  proofs.  Second,  it  consolidates  complle-time  and  run- 
time specifications,  enabling  the  system  to  take  full  advantage  of  the  Interrelationship  between 
verification  and  run-time  validation  by  assuming  the  specifications  to  be  checked  at  run-time  In 
the  verification.  Third,  It  contains  constructs  for  error  handling  and  for  stating  and 
specifying  data  abstractions  and  concurrent  processes,  extending  the  kinds  of  programs  that  can 
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br  considered.  Gypsy  also  eliminates  a few  constructs,  such  as  go  to  statements  and  labels,  that 
are  handled  in  some  of  the  other  systems. 

Concerning  proof  methods,  five  of  the  systems  reviewed  are  based  on  Inductive 
as.sertions,  and  Boyer-Moore  uses  structural  induction.  Other  methods  can  be  found  in  a few 
systems  not  reviewed  here,  eg.,  computational  induction  [Milner  72]  and  continuation  Induction 
[1  opor  75].  SID  employs  inductive  assertions,  plus  the  methods  described  In  Good  [77]  for 
proving  data  abstractions  and  concurrent  processes. 


Verified  Programs 

Programs  verified  In  previous  systems  are  sequential  and  characteristically  small  in 
sire,  yet  often  logically  complex.  They  include  certain  array  sorting  and  rearrangement 
programs,  algebraic  computation  programs  such  as  square  root,  quotient,  factorial,  and 
exponentiation,  and  tree  searching,  pattern  matching,  and  unification  programs. 

An  advantage  of  studying  these  previously-uscd  examples  is  that  generally  they  are 
simple  enough  to  be  easily  grasped.  This  is  good  for  expository  purposes,  but  there  Is  a danger 
In  considering  only  these  since  they  do  not  provide  a very  good  metric  on  what  else  systems  can 
do.  Therefore,  the  focus  here  is  on  moving  Into  a very  different  kind  of  area  in  which  there 
has  been  little  If  any  prior  work  --  communications  processing  systems.  The  intent  Is  to  apply 
SID  to  large,  realistic  programs,  thereby  establishing  a better  base  from  which  to  Judge  its 
practical  utility  and  philosophy. 

Currently,  the  message  switching  network  in  Appendix  A Is  the  largest  and  most 
complex  program  completely  designed  and  verified  using  SID. 
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CHAPTER  3 
THE  SYSTEM 


3.1  System  Overview 

Figure  3-1  illustrates  the  high-level  system  design;  this  is  also  how  the  user  views  the 
overall  system.  SID  consists  of  four  parts:  a dcsigner/verifier’s  assistant  (or  simply  assistant),  a 
translator,  a VC  generator,  and  a proof  system.  The  human  designer/verifier  communicates 
with  the  assistant,  which  invokes  the  translator  for  parsing  or  type  checking,  the  VC  generator 
for  generating  VCs,  or  the  proof  system  for  proving  a formula  The  assistant  is  the  new 
component  In  this  scenario;  some  form  of  the  other  components  have  traditionally  been 
included  In  earlier  verification  systems  (cf.  Chapter  2).  The  idta  behind  the  assistant  is  that 
the  user,  instead  of  talking  to  a passive  system  that  responds  to  each  Input  and  then  waits  for 
the  next,  talks  to  an  active,  helpful  intermediary.  1 he  assistant  embodies  an  incremental, 
ititegrated  view  of  design  and  verification  and  ties  together  the  other  components  to  convey  this 
view  to  the  user. 

The  a.ssistant  is  organized  as  shown  in  Fig.  3-2  Its  user  interface  is  discussed  in 
Section  3 2,  which  also  gives  an  overview  of  SID's  explanation  facility  as  a prelude  to  a 
di.sciission  of  the  natural  language  part  of  the  Interface.  Section  3-3  describes  all  of  SID’s 
incremental  capabilities.  1 he  majority  are  provided  solely  by  the  assistant,  specifically  the 
design  and  verification  manager  (abbreviated  as  DVM),  using  the  methods  of  Chapter  4.  The 
others  require  interactions  which  are  discussed  here  between  the  DVM  and  other  components. 
The  a.ssistant’s  data  base,  whose  organization  is  presented  in  Section  4.2,  is  often  referred  to  as 
simply  "the  data  base".  Section  3-4  focuses  on  SID's  design,  discussing  its  important  overall 
characteristics  and  the  functional  capabilities  of  the  traditional  system  components.  The  impact 
of  an  integrated,  incremental  view  of  design  and  verification  on  SID's  design  is  emphasized. 
Some  implementation  details  (eg.,  SID's  memory  requirements)  are  presented  in  Section  3-5. 
The  example  session  in  Section  1.2  Is  referred  to  throughout  this  chapter. 


3.2  User  Interface:  Gjmmands,  Suggestions,  and  English  Queries 


SID  interacts  with  the  user  by  accepting  and  executing  commands,  by  proposing 
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Figure  3-1 . High-level  struc^ure  of  SID 

actions,  and  by  conversing  about  the  effects  of  changes.  Each  of  these  aspects  of  Its  user 
Interface  is  discussed  in  this  section. 

Command  Language 

SID’s  command  language  includes  several  kinds  of  control,  help,  print,  and  query 
commands.  Each  command  begins  with  an  initial  keyword  that  identifies  its  main  function,  as 
summarized  in  Fig.  3-3.  For  variations  in  command  execution,  some  commands  allow 
subcommands,  which  are  further  keywords  that  select  options  or  arguments  that  tell  what  to  act 
on.  The  print  command,  for  example.  Is  used  to  display  user-defined  data  (e.g.,  individual  or 
collections  of  programs,  specifications,  assumed  properties,  or  VCs)  and  system-generated  data 
(e  g.,  status  summaries). 

Full  and  abbreviated  input  styles  are  allowed.  The  user  can  type  any  keyword  in  its 
entirety  or  type  an  unambiguous  abbreviation  of  it.  Arguments  can  also  be  abbreviated  and 
sometimes  even  omitted. 
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Default  assignments  are  automatically  supplied  in  some  contexts  by  SID  If  the  user 
declines  to  specify  a particular  argument  himself.  The  heuristic  employed  is  to  default  to  the 
’ last  legal  program  name  typed  by  the  user  or  by  the  system  In  a suggestion,  or  to  the  first 
verifiable  program  on  the  last  translated  file,  whichever  Is  most  recent.  This  heuristic 
encourages  a top-down  approach  to  design  and  verification.  In  the  sorting  program 
development  in  Section  1.2,  the  default  is  initially  £xchange_sort,  then  Location-of_max,  then 
Fxchange.  The  impact  of  this  heuristic  is  even  more  evident  In  the  more  lengthy  network 
development  In  Appendix  A. 

Making  Suggestions  to  the  User 

The  suggestion  mechanism  is  valuable  for  experienced  as  well  as  novice  users  of 
SID.  It  can  guide  the  user  through  the  design  and  verification  of  an  entire  program,  whether  It 
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Command 

Funct ion 

ADI) 

Parse  and  type  check  new  lemma 

I)Kl,F.TE 

Delete  lemma 

EDIT 

Invoke  text  editor  * 

EXPLAIN 

Enter  explanation  facility 

HELP 

Explain  command (s) 

PRINT 

Display  information 

PROVE 

Attempt  proof  of  formula 

RESTORE 

Restore  a previously-saved  problem  state 

SAVE 

Save  the  current  problem  state 

SUGGEST 

Propose  an  act  ion  * 

TRANSLATE 

Parse  and  type  check  data  on  file 

VIS 

Generate  VCs 

TF.  (control  E) 

Delete  current  word  * 

? 

List  currently  allowed  options  » 

?? 

List  full  syntax  for 

remaining  allowable  options 


* indicates  no  subcommands  available 

Figure  3-3.  Summary  of  commands 

consists  of  Just  a few  programs  or  of  a sizeable,  perhaps  intellectually  unmanageable,  number  of 
programs.  T hree  main  characteristics  of  this  mechanism  are  Its  ability  to: 

• Always  have  available  a reasonable  suggestion  for  the  next  step  in  the  design 
and  verification. 

• Base  suggestions  on  the  current  state  of  development. 

• Make  suggestions  easy  to  obtain,  while  not  Impeding  the  invocation  of  other 
desired  operations. 

Some  design  issues  relating  to  the  first  two  characteristics  are  discussed  before  looking  at  the 
actual  implementation;  the  last  is  accomplished  by  the  straightforward  convention  for 
transferring  between  command  and  suggest  mode  illustrated  In  Section  1.2.  A similar 
mechanism  is  described  In  Yonke  [76]. 


V 

I 


The  key  issue  involved  In  generating  suggestions  is  that  of  priorities  - what 
suggestions  should  be  given  when.  Representative  Issues  confronting  the  suggestion  mechanism 
are:  Should  operations  on  partially-defined  programs  be  suggested  before  or  after  operations 
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on  rully  defined  ones?  Is  their  manipulation  Interspersed  rather  than  sequential?  Should 
completing  the  proof  of  partially-proved  VCs  be  suggested  before  or  after  trying  completely 
unattempted  proofs  is  suggested?  What  about  programs  verified  in  varying  degrees?  What 
Impact  do  Incremental  changes  have  on  suggestion  generation? 

This  priority  Issue  Is  addressed  here  by  basing  the  order  of  suggestions  on  a pre- 
imposed priority  class  structure.  The  scheme  for  keeping  track  of  suggestions  Is  naturally  a 
priority  queue.  Each  suggestion  is  assigned  a fixed  priority  number  when  It  is  created,  then 
placed  In  the  queue  ahead  of  lower  priority  suggestions  and  behind  suggestions  of  equal  or 
higher  priority.  The  next  suggestion  Is  always  at  the  front  of  the  queue.  If  a suggestion  Is 
executed  or  no  longer  appropriate,  It  Is  removed  from  the  queue. 

I'o  illustrate  the  suggestion  mechanism  In  action,  the  queue  manipulations  that  took 
place  during  the  development  In  Section  1.2  will  be  traced,  accompanying  each  manipulation  by 
the  suggestion  SID  made  (or  would  have  made  had  it  been  In  suggest  mode).  The  priority 
queue  is  represented  as  an  ordered  list  of  sublists,  where  each  subllst  is  a triple  of  the  form 

(priority  oporation  object) 

T he  queue  Is  empty  when  It  contains  no  such  entries. 

When  the  session  begins,  the  suggestion  queue  Is  empty  and  SID  types 

Sugftest  one  of: 

<esc>TRANSLATE  (from  file) 

RESTORE  (problem  from  file) 

The  Initial  version  of  Exchange_sort  plus  data  definitions  N and  Int_array  are  entered  into  the 
system.  The  updated  queue  is 

( (5  CorrectSemantics  Exchange_tort)  ) 

N and  Int_array  do  not  have  queue  entries  because  they  are  not  to  be  verified.  The  suggestion 
typed  Is 


Suggasl  corroding  the  semantics  of  Exchange_sorl 

Indicating  the  need  to  correct  the  type  errors  In  Exchange_sort.  After  this  Is  done,  the  queue  is 
updated  to 

( (5  GeneratoVCs  EKchanga_jsort)  ) 


and  SID  types 
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Suggest  generating  VCs  for  Exchange_sorl 

Execution  of  this  operation  results  In  three  VCs  and  the  discovery  of  a pending  path. 

( (5  Provo  Exehange_sort«l ) .(3.1) 

(5  Prove  Exchange_sorla2) 

(5  Prove  Exchange_sorl«3) 

(4  PullyDefine  Exchange_Bort  ) ) 

Priority  assignments  encourage  top-down  development  and  thus  complement  the  scheme  for 
making  default  assignments  In  commands.  Here,  proving  existing  VCs  has  a higher  priority 
than  continuing  the  design.  The  following  suggestions  are  made,  accepted,  and  successfully 
carried  out  In  sequence. 

Suggest  proving  VC  called  Exchange_sortol 
Suggest  proving  VC  called  Exchange_sort«2 
Suggest  proving  VC  called  Exchange_sort«3 

The  remaining  queue  entry  is 

( (4  PullyDefine  Exchango_jBort)  ) (3.2) 

So  SID  suggests  continuing  the  design  by  typing 

Suggest  fully  defining  Exchange_sort 

The  user  completes  the  implementation  of  Exchange_sort  and  also  makes  several  other  changes 
to  the  overall  design.  The  only  ones  affecting  the  suggestion  queue  are  the  Introduction  of 
functions  Location_Df_max  and  Exchange. 

( (5  GenerateNewVCs  Exchango_sort  ) 

(4  PullyDefine  Location_of_max) 

(4  PullyDefine  Exchange  ) ) 

The  next  suggestion  is 

Suggest  generating  new  VCs  for  Exchange-jsort 


After  four  new  VCs  are  generated,  the  queue  entries  are 
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( (5 

Prove 

E*chan(!e_sorta4) 

(5 

Prove 

Exchan('e_sorta5) 

(5 

Prove 

Exchan|;e_torta6) 

(5 

Prove 

Exchan(’e_tori*7 ) 

(4 

PullyDeiine 

Location_ol_max) 

(4 

FullyDefine 

Exchange  ) ) 

After  suggestions  to  prove  these  VCs  are  given  and  carried  out,  suggestions  parallel  those 
beginning  with  queue  configuration  (3.2).  Locatlon_of_max,  followed  by  Exchange,  is 
implemented  and  verified.  Afterwards,  the  suggestion  queue  is  empty  and  SID  types 

Suggest  one  of: 

<esc>  TRANSLATE  (from  file) 

SAVE  (problem  on  file) 

When  the  queue  is  empty,  suggestions  are  based  on  whether  or  not  the  system  data  base  is 
empty.  The  data  base  Is  empty  only  at  the  beginning  of  a problem,  whereas  the  suggestion 
queue  is  empty  at  the  beginning  and  at  the  end. 

A slightly  complicating  factor  - which  is  a by-product  of  SID’s  dual-mode 
philosophy  - not  encountered  in  the  above  scenario  is  the  problem  of  updating  the  suggestion 
queue  when  the  user  issues  a command  whose  execution  affects  an  entry  (or  entries)  already  in 
the  queue.  As  an  illustration  of  how  the  queue  Is  manipulated,  suppose  that  the  queue  is 
configured  as  in  (3.1)  and  that  the  user,  instead  of  accepting  the  suggestion  to  prove 
F.xchange_sort*l,  modifies  the  Implementation  of  Exchange-sort.  Then,  all  entries  relating  to 
F.xchangc_sort  are  removed  and  a new  suggestion  such  as 

( (5  GenaratsNawVCs  Exchange_sort)  ) J 

Is  added.  When  VCs  are  generated  for  Exchange_sort,  entries  for  those  VCs  that  remain  valid  I 

are  reentered.  I 


Conversing  about  the  effects  of  changes 

SID’s  explanation  facility  answers  questions  about  what  the  effects  of  changes  are 
and  about  why  a change  has  the  determined  effects.  When  the  user  types  a question,  SID  goes 
through  three  steps: 


• If  nderstM  ndi  ng  the  question.  A simple  pattern  matching  scheme 
which  looks  for  keywords  works  well  for  SID’s  limited  domain  of  discourse. 
Context  Is  used  only  In  re.solvlng  pronoun  references.  These  patterns  of 
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keywords  are  translated  into  calls  to  Functions  responsible  for  answering  the 
question.  If  a question  is  not  understood,  the  user  is  informed  of  the 
allowable  options  for  the  missing  or  incorrect  sentence  fragments. 

• Getting  the  answer.  This  Involves  two  interleaved  processes  -- 
figuring  out  the  answer  and  formatting  it.  Functions,  called  from  Step  I, 
Interface  with  the  methods  of  Chapter  4 to  determine  the  effects  of  changes 
and  generate  the  appropriate  English  output  by  fitting  the  results  of  the 
methods  into  language  templates.  These  templates  are  assembled  dynamically 
from  smaller,  standardized  templates  that  are  designed  to  fit  very  specific 
situations.  Answers  to  "why"  questions  are  more  detailed  In  some  respects 
than  answers  to  "what"  questions. 

• Reporting  the  answer.  A set  of  routines  for  formatted  printing  of 
templates  is  used  for  typing  the  English  answer  on  the  terminal. 

Figure  3-1  illustrates  the.se  steps.  This  section  focuses  on  the  natural  language  interface  portion 
of  the  explanation  facility. 

The  workings  of  this  English  Interface  are  illustrated  using  an  excerpt  from  the  final 
conversation  In  Section  1.2  (shown  in  Fig.  3-5).  Figure  3-6  explains  the  role  of  keywords  used 
In  forming  the  function  calls  needed  to  gel  the  answers.  Although  not  used  in  function  call 
formation,  verbs  are  also  recognized.  1 his  is  done  to  Increase  the  likelihood  of  the  answer 
making  sense.  1 he  dictionary  of  keywords  contains  verbs  meaning  "alter"  (eg.,  alter,  change, 
n»odify,  and  replace)  In  several  tenses  Figure  3-7  shows  how  final  answer  templates  are  built 
by  filling  in  Intermediate  templates,  which  represent  part  of  the  answer,  with  actual  problem- 
specific  data.  The  methods  of  Chapter  1 are  used  at  each  step  to  guide  the  choice  of  templates 
and  to  supply  actual  data  for  filling  them  in.  The  answer  template  is  then  typed  on  the 
terminal  as  English  text  by  routines  designed  especially  for  this  purpose.  Notice  in  Fig.  3-5  that 
the  answer  to  the  "what"  question  identifies  the  program  Exchange_sort  as  potentially  being 
affected  by  the  change,  while  the  answer  to  the  "why"  question  isolates  the  potential  effects  to 
VCs  Exchange_sort*5  and  Exchangc_sort#7. 
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<-  What  tf  the  •ffectt  of  chaneing  tha  antrv  atta rtion  of  Location_of_mwT 


<“  What  doas  changing  itt  exit  assertion  affactT 

Changing  tha  axit  spacification  of  LOCATION_OF^MAX  doas  net  atfact 
LOCATION_OF_MAX  if  tha  formula 
HI:  LOCATION_OF_MAX(A,  I,  J)  in  [I.  J] 

H2:  A[LCX:ATI0N_0F_MAX(A,  I,  J)]  « VALUE_OF_MAX(A,  I,  J) 

— > 

Changed  exit  apacification 

ia  true.  If  not,  aoma  of  LOCATION_OF_MAX’a  VCa  are  incorrect.  Tha  verification 
of  other  programa  ia  not  affected  if  tha  formula 
Changed  exit  apacificafion 
"> 

Cl:  LOCATION_OF_WAX(A,  I,  J)  in  [I.J] 

C2:  A[LOCATION„OF_MAX(A,  I,  J)]  « VALUE_0F_>4AX(A,  I,  J) 
ia  true.  If  not,  tha  change  invalidataa  tha  verification  of  EXCHANGE_$ORT. 


<-  Why 


Tha  affacta  on  LOCATION_OF_MAX  are  a change  in  ita  VCa.  Invalid  varificatien 

bacauaa  propartiaa  from  LOCATION_OF_MAX  ware  uaad  in  proving  EXCHANGE SORToS 

and  EXCHANGE_SORTo7. 


Figure  3-5. 


Sample  questions  and  answers 


...  Location_of_max? 


( FindEffects  Location_of_max 


Function  Arguments 


Figure  3-6.  Translating  questions  of  Fig.  3-5  into  function  calls 


Page  S9 


The  verification  of  other  programs  is  not  affected  if  the  formula 
Changed  exit  specification 

— > 

Cl:  LOCATION_OF_MAX(A,  I,  J)  in  [I..J] 

C2!  A[LOCATION_OF_MAX(A,  I,  J)]  = VALUE_OF_MAX<A,  I,  J) 
is  true.  If  not  tho  change  invalidates  the  verification  of  EXCHANGE_SORT. 


Problem-specific  data 


Figure  3-7 


Assembling  port  of  answer  to  "what"  question  of  Fig.  3-6 
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3.3  Incremental  Capabilities 

One  important  point  needs  to  be  emphasized  before  going  on.  SID’s  incremental 
capabilities  were  designed  to  collectively  convey  an  incremental  view.  They  are  highly 
integrated  and  complementary,  as  seen  in  the  session  In  Section  1.2.  Thus,  the  overall  scenario 
should  be  kept  In  mind  when  reading  the  Individual  descriptions  below. 

Designing  and  verifying  programs  Involves  four  major  activities  - overall  problem 
development,  design  refinement  (evolving  the  set  of  programs,  specifications,  and  assumed 
properties),  VC  generation,  and  proof  development.  Each  activity  is  broken  down  according  to 
the  user’s  view  of  the  kinds  of  capabilities  provided  by  SID.  Unless  covered  in  Chapter  4,  a 
discussion  of  how  a capability  is  provided  follows  Its  description. 

The  discussion  of  the  incremental  aspects  of  SID  here  and  In  Chapter  4 focuses  on 
what  was  done.  Some  alternatives  and  tradeoffs  are  discussed  in  Chapter  5. 


Overall  Problem  Development 

Obtaining  a problem  solution,  for  reasons  such  as  size  and  complexity,  Is  typically  an 
evolutionary  process  requiring  an  extended  period  of  time  (often  several  sittings  with  the 
system).  Therefore,  a capability  is  provided  that  enables  the  user  to  temporarily  interrupt  the 
problem  development,  then  resume  working  on  it  in  the  same  state  at  a later  time. 

If  the  user  types 


Exec->  Say  Sort.Dmp 


the  DVM  saves  the  current  problem  state  on  the  file  Sort.Dmp.  This  requires  collecting  all 
data  that  defines  the  current  problem  state  and  then  writing  it  on  the  file  Sort.Dmp  In  a format 
suitable  for  restoration.  Typing 


Exec-)  Raslora  Sori.Dwp 


causes  the  save  file  Sort.Dmp  to  be  read  back  into  the  system,  replacing  the  current  state  with 
the  one  recorded  on  Sort.Dmp. 


Page  i I 


What  information  needs  to  be  collected?  How  can  It  be  collected?  Are  there  any 
formatting  problems?  These  are  some  of  the  questions  that  often  create  problems  when 
providing  this  kind  of  capability.  Due  to  the  overall  system  design  - in  particular,  the 
centralization  of  information  in  the  assistant's  data  base  - such  questions  pose  no  problems 
here.  The  DVM  simply  writes  out  this  single  data  base  to  temporarily  discontinue  a problem, 
then  reads  it  back  in  to  resume  a problem. 

Design  Refinement 

1 ypically,  a problem  consists  of  a large,  highly-interrelated  collection  of  information, 
including  programs,  specifications,  and  properties  assumed  In  proofs.  The  focus  here  1$  on  how 
SIF)  aids  in  evolving  the  final  design  of  this  interwoven  problem  structure. 

Changing  the  design.  The  user  can  add  new  or  change  already-defined  programs, 
specifications,  or  properties  assumed  in  proofs,  letting  SID  assume  the  burden  of  determining 
the  design-related  effects.  Changes  arc  made  for  several  reasons  - to  correct  an  error  in  a 
program  or  specification,  to  augment  or  reformulate  a program  or  its  specifications,  to  add  a 
new  program  or  assumed  property,  and  so  on.  SID,  by  figuring  out  the  impact  of  changes, 
allows  the  user  to  concentrate  on  the  essentials  of  determining  the  appropriate  change. 

The  DVM  analyzes  changes  to  the  design  with  the  Intent  of  avoiding  complete 
retranslation  (and  reverification  too).  Of  course,  in  some  cases  it  cannot  be  avoided.  Changing 
the  number  or  types  of  arguments  of  a function,  for  example,  requires  that  all  calls  on  the 
function  be  checked.  Therefore,  those  programs,  specifications,  and  assumed  properties  that  do 
not  call  the  changed  function  need  not  be  (and  are  not)  rechecked.  Sections  4.3-4.5  give  the 
relevant  algorithms. 

Partially  stating  programs.  Just  as  an  incomplete  overall  design  is  gradually  filled 
in  and  refined,  programs  within  the  overall  design  structure  are  developed  Incrementally.  The 
u.ser  can  define  parts  of  a program  and  leave  other  parts  to  be  defined  later.  This  aids  In 
doing  top-down  design  and  verification.  For  example,  partially  defining  Exchange  as 

function  EKchanfto(A:int__array;  l,J:inl):int_array  * 
basin 

antry  I in  [I  N]  and  J in  [i..N]; 
axil  (allk:[I  . N], 

k na  I and  k na  J ->  Exchansa(A,l,J)[k]  ■ A[k]  ) 
and  lsExchansad(A,Exchansa(A,l,J),l,J) 
and  lsParm(A,Exchansa(A,l,J)); 
pandins 
and; 
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allows  its  header  to  be  used  for  type  checking  Exchange_sort  and  its  specifications  to  be  used  In 
the  proof  of  Exchange_sort.  Later,  the  pending  body  is  replaced  by  executable  code 

function  ExchanKo(A:inl_array;  l,J:inl):int_array  « 
begin 

entry  I in  {1..N]  and  J in  [1..N]; 
exit  (all  k:[  I ..N], 

K ne  I and  k ne  J ->  Exchanee(A,l,J)[k]  ■ A[k]  ) 
and  lsExehanged(A,Exchango(A,l,J),l,J) 
and  lsPerm(A,Exchange(A,l,J)); 
result  A; 
result[l]  :■  A[J]; 
result[J]  :■  A[l]$ 
end; 

and  Exchange  is  verified. 

There  are  three  main  uses  of  pending  handled  by  SID. 

Body  of  routine  and  type  definitions.  The  body  of  a routine  (i.e.,  a function, 
procedure,  process,  or  program)  or  type  definition  may  be  left  pending  in  several  ways. 
Example  uses  In  a routine  are; 


function  ...  « ponding; 
function  ...  « begin  entry  ...;  pending  end; 
function  ...  * begin  var...;  pending  end; 
function  ...  > begin  pending  end; 

Notice  that  all  headers  (I.e.,  the  entities  to  the  left  of  the  symbol)  are  complete  so  that  type 
checking  of  callers  can  be  done.  The  second  construction  serves  the  additional  purpose  of 
allowing  properties  to  be  stated  about  the  pending  function  that  can  be  used  In  premfs  of 
calling  programs. 

Some  uses  of  pending  In  type  definitions  are; 

type  X K ponding; 

typo  X ■ bogin  axiom...;  ponding  ond; 
typo  X B bogin  ponding  ond; 

The  second  construction  allows  the  axiom  specification  to  be  used  for  verification  purposes.  Just 
as  routine  specifications  were  made  available  above. 
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Statement  list  in  routine  bodies.  A pending  statement  list  In  a routine  body  Indicates 
that  a particular  section  of  the  body  has  not  been  written.  Typical  uses  Include: 

if  ...  then  pending  end; 
if  ...  then  ...  else  pending  end; 
loop  pending  end; 

case  ...  is  ...:pending;  is  ...  ipending;  else  ...  end; 

Mandling  a program  with  a pending  body  and  handling  a program  with  a pending  statement 
list  differs  concerning  the  generation  of  VCs.  Maybe  some  VCs  can  be  generated  for 
programs  containing  pending  statement  lists,  whereas  those  with  pending  bodies  have  no  VCs. 

Constant  and  variable  initializations.  A pending  constant  or  variable  Inltlalliatlon 
value  Indicates  that  the  programmer  has  not  as  yet  decided  the  Initial  value  that  should  be 
assigned  to  the  particular  entity.  A pending  constant  definition  Is  of  the  form; 

const  x:  lyp  ^ pending; 

This  construction  Is  allowed  for  both  global  and  local  constant  declarations.  A pending 
variable  Initialization  is  of  the  form 

var  x:  lyp  * pending; 

These  uses  of  pending  allow  as  yet  undetermined  constants  to  be  "specified".  In  VC  generation 
and  In  the  prcxjf  process,  these  pending  values  are  treated  as  unique  symbolic  constants.  Thus, 
proofs  succeed  without  knowledge  about  the  value  eventually  asslgjned.  Notice  that  pending 
constants  and  variables  must  have  declared  types  for  type  checking  purposes. 


VC  Generation 

To  convey  a unified,  consistent  view  of  the  task  to  the  user,  VC  generation  activities 
must  directly  reflect  steps  taken  In  the  design  process.  This  Is  done  by  generating  (when 
possible)  some  VCs  for  partially-stated  programs  and  by  generating  only  new  VCs. 

Generating  VCs  for  parts  of  programs.  When  a program  Is  only  partially  stated, 
VCs  are  generated  for  only  those  paths  that  are  completely  defined.  For  example, 
F.xchange_sort  Is  defined  initially  as 
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function  Exeh«ngo_j»orl(A!inf_8rray):inl_Brr8y  ■ 
begin 

entry  N ge  I ; 
exit  (ell  l:int, 

lintl.N]->  Exchange_j80ri{A)[l] 

= Value_o(_max{Exchange_*ort(A),l  ,1)) 
and  lsPertn(A,  Exchange_sort(A)); 
var  B:int_array  :«  A; 
var  K:int  :■  N; 

Keep  Kin[I..N]; 
loop 

assert  (all  hint,  I in  [K*1..N]  ->  B[l]  * Value_o( max(B,l,l)) 

andKin[I..N]  and  lsPerm(A,B)i 
if  K B I then  leave  else  pending  end; 
end; 

result  :■  B; 
end; 

F.ven  though  this  definition  is  incomplete  (the  else  branch  of  the  If  statement  Is  pending),  some 
VCs  can  be  generated.  As  shown  below,  VCs  are  generated  for  the  path  from  the  entry  of 
F.xchange_sort  to  its  loop  assertion  and  for  the  path  from  Its  loop  assertion  to  Its  exit,  whereas 
that  path  through  the  loop  must  be  handled  later  when  the  else  branch  is  fully  defined. 


Beginning  new  path... 

B :■  A 

K ;«•  rf 

Assume  (’.^nit  entry  condition) 
N go  I 


ASSERT  (alllelHNT,  1*1  in  (K»l  ..N] 

->  B[lal  J B VALUE_OF_MAX|B,  1,  Ixl)) 

and  K in  [I ..N] 
and  ISPERM(A,  B) 


Must  verify  ASSERT  condition 
Verification  corrdition  EXCHANGE_SORTel 
HI:  I lo  N 
— > 

Cl:  ISPERM(A,  A) 
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End  of  path 


Beginning  new  path... 

Continuing  in  LOOP  ... 

Assume  (from  last  assertion) 

(allleltINT,  lal  in  [K*l  ..N] 

->  Btl*l)  « VALUE_OF_MAX(B,  1,  la|)) 

and  K in  [I  ..N] 
and  ISPERM(A,  B) 


Assume  (KEEP  assertion) 
K in  [I  ..N] 


Assume  (IF  lest  failed) 

(not  K^l) 

Entering  PENDING  statement...cannot  continue  in  this  path 
End  of  path 


Beginning  new  path... 

Continuing  in  LOOP  ... 

Assume  (from  last  assertion) 

(allla|:lNT,  la)  in  [KM..N] 

->  B[l«l]  - VALUE_OF_MAX(B,  I,  lal)) 

and  K in  [I  N] 
and  l$PERM(A,  B) 
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Lvaving  unit  EXCHANGE_SORT 
ASSERT  (alll:INT,  lin[I.N] 

->  RESULT[I]  = VALUE_OF_MAX (RESULT,  1, 1)) 
and  ISPERM(A.  RESULT) 


Must  verify  (unit  axit)  condition 
Verification  condition  EXCHANGE_S0RT«3 
HI:  all  la]  ; INT,  I"!  in  [K*1..N]  ->  VALUE_OF_MAX(B,  1,  HI)  ■ B[lal] 
H2:  K=J 

H3:  ISPERM(A,  B) 

H4;  K in  [1..N) 

"> 

Cl:  all  I : INT,  I in  [l.N]  ->  VALUE_OF_MAX(B,  1, 1)  = B[l] 


End  of  path 


The  fact  that  a VC  cannot  be  generated  for  the  else  branch  (on  the  second  path)  is  detected  by 
the  VC  generator. 

The  previous  discussion  about  the  uses  of  pending  mentioned  that  pending  values 
are  treated  as  unique  symbolic  constants.  This  impacts  the  prcKess  of  generating  VCs.  The 
VC  generator,  upon  recognizing  a pending  as  an  Initialization  value,  assigns  the  asstKiated 
identifier  a unique  name  (which  turns  out  to  be  the  identifier  itself)  for  which  no  initial  value 
Is  substituted.  Thus,  such  Identifiers  are  treated  as  representing  some  unknown,  yet  fixed, 
value.  The  VC  generator  recognizes  a pending  in  local  initializations  by  its  ordinary  path 
transversal  algorithm.  Global  constants  that  have  pending  values  are  detected  via  the  DVM, 
which  Is  aware  of  all  pending  entities.  The  DVM  ensures  that  global  names  are  handled 
properly  not  only  during  VC  generation  but  also  during  proofs. 

Generate  only  new  VCs.  Changes  to  the  design  often  affect  the  verification.  For 
example,  changing  a statement  In  a program  can  change  the  set  of  VCs  that  need  to  be  proved 
for  that  program.  Or  changing  the  number  of  arguments  in  the  parameter  list  of  a function 
Invalidates  some  (but  not  necessarily  all)  VCs  of  its  callers.  SID,  from  the  user’s  viewpoint, 
responds  to  changes  by  generating  only  new  VCs  and  by  not  regenerating  VCs  unaffected  by 
the  change. 

This  capability  Is  illustrated  by  replacing  the  pending  In  Exchange_sort  with 
executable  code  and  then  generating  Its  VCs.  The  new  version  of  Exchange-sort  Is 


function  Exchango_aort(A:ini_array):inl_arrsy 
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bafin 

•ntry  N ga  1 ; 
axil  (all  l:int, 

I in  [I  N]  *>  EKchange_Borl(A)[l] 

> Valua_of_max(Exchanga_sort(A),l  ,1)) 
and  lsParm(A,  Exchanga_tort(A)); 
var  B:in(_array  :«  A; 
var.  K:int  :«  N; 

Keep  Kin[I  ..N]; 
loop 

assert  (all  hint,  I in  [K*I..N]  •>  B[l]  « Vaiue_of_max(B,l,l)) 
andKin[l..N]  and  lsPerm(A,B); 
if  K > I then  leave  and; 

B :■  Exchanga(B,Location_of_max(B,l,K),K); 
k ;»  K-I; 
and; 

result  t>  B; 
and; 

SJD  traces  the  one  changed  path  through  the  loop  and  generates  new  VCs. 


Beginning  new  path... 

Continuing  In  LOOP  ... 

Assume  (from  last  assertion) 

(alllaltlNT,  |s|in[K*l.N] 

->  BpalJ  « VALUE_OF_MAX|B,  1,  1*1 )) 

and  K in  [I..N] 
and  ISPERM(A,  B) 


HI:  all  |a|  : INT,  I*!  in  IKM  .N]  ->  VALUE_OF_MAX{B,  1,  lal)  « B[lall 
H2:  ISPERM(A,  B) 

H3:  (K-1)  in  [I  ..N] 

H4:  K in  [I  ..N] 

H5: K na  I 
— > 


Cl:  all  1*1  t INT,  |al  in  [K..N] 

->  VALUE„OF_MAX(EXCHANGE(B, 

LOCATION_OF_MAX(B,  1,  K),  K),  I,  |a|) 
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« EXCHANGE(B,  LOCATION_OF_MAX<B,  1,  K),  K)[»*J] 
C2:  ISPERM(A,  EXCHANGE(B,  LOCATION_OF_MAX(B,  I,  K),  K)) 


End  of  path 


UnaffocUd  VCs:  EXCHANGE_SORTal,  EXCHANGE_S0RT«2,  EXCHANGE_S0RT«3 

Three  previously-generated  VCs  (which  came  from  the  unchanged  paths)  were  unaffected  by 
the  change. 

The  scheme  employed  by  the  DVM  for  generating  only  new  VCs  is  discussed  in 
Section  1.7. 


Proof  Development 

The  incremental  aspects  of  proving  formulas  both  complement  and  augment  the 
other  incremental  activities.  1 he  term  "formula"  refers  to  both  VCs  and  problem-domain  facts 
assumed  in  proofs.  1 he  interface  between  the  DVM  and  proof  system  is  critical  in  attaining 
SID’s  proof  development  capabilities.  1 he  part  of  the  proof  system  of  Interest  here  is  its 
interactive  theorem  prover  (abbreviated  as  prover),  which  is  an  extension  of  the  program 
described  in  Bledsoe  and  Tyson  [75].  The  DVM-prover  interface  is  divided  according  to  three 
main  tasks: 

1.  Getting  started.  1 he  DVM  invokes  the  prover  with  the  Information 
necessary  to  attempt  the  proof  of  the  designated  formula.  The  DVM 
retrieves  this  Information  from  the  data  ba.se  of  the  assistant. 

2.  Adding  to  the  proof.  During  the  proof  process  the  prover  may  (and 
typically  docs)  invoke  the  DVM  to  obtain  additional  Information.  The 
DVM  performs  the  necessary  error  checking  (does  the  information  exist  and 
can  it  be  used  in  this  context?);  then  if  the  request  if  valid,  the  DVM 
retrieves  the  data  directly  from  the  data  base  (eg.,  a basis  property  or 
complete  specification),  or  docs  the  appropriate  manipulations  to  get  it  (e.g., 
by  separating  out  the  unwanted  parts  of  a specification). 

8.  Concluding  a proof.  Upon  the  completion  of  a proof,  the  DVM 
interprets  and  stores  the  results  of  the  attempted  proof.  Results  of  a 
successful  prewf  include  a detailed  record  of  the  proof  that  makes  explicit 
steps  in  derivations  along  with  their  Justifications. 
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Krrping  this  Interface  In  mind  will  aid  In  understanding  how  SID’s  proof -related  activities  are 
arrompllshed. 

Prove  only  unproved  formulas.  Changes  not  only  affect  VCs,  they  also  affect 
proofs,  1 his  Is  seen  by  reconsidering  the  example  of  changing  the  number  of  arguments  to  a 
function.  I'his  causes  a type  mismatch  in  all  of  its  callers.  Suppose  that  this  function  Is  called 
by  a.ssumed  properties  or  specifications  used  in  proofs.  Then,  proofs  using  these  properties 
must  be  redone.  As  another  example,  suppose  that  a prevlously-used  property  Is  Incorrect. 
Revising  this  property  may  or  may  not  affect  the  proofs  In  which  It  was  used.  Section  4.8 
di.scusses  the  techniques  employed  by  the  DVM  to  determine  what  proofs  (If  any)  need  to  be 
redone  when  changes  affect  properties  u.sed  In  proofs. 

After  the  DVM  applies  the  methods  of  Section  4.8  to  Identify  what  proofs  need  to  be 
redone,  the  remaining  problem  Is  how  to  retain  still  valid  parts  of  these  proofs.  The  DVM 
supplies  the  prover  with  the  relevant  proof  records  that  need  to  be  at  least  partially  redone  and 
the  revised  properties.  1 he  prover  tries  to  reprove  the  affected  subgoals  while  ensuring  that 
the  proofs  are  consistent  with  other  parts  of  the  original  proof.  1 he  proof  record  is  used  to 
supply  the  necessary  context.  For  example,  the  prover  must  be  aware  of  all  substitutions  made 
In  proofs  and  also  the  context  In  which  they  were  made  because  substitution  conflicts  may 
invalidate  previous  deductions.  The  prover  currently  accepts  reproofs  when  substitutions  made 
In  a stibgoal's  new  proof  subsume  those  made  in  Its  previous  proof. 

This  completes  the  linking  of  changes  In  the  design  to  proofs.  When  design  changes 
affect  VCs,  the  methods  of  Section  4 7 keep  Intact  still  valid  ones  along  with  their  proofs. 
When  design  changes  affect  properties  used  In  proofs,  the  two  step  process  Just  described  is 
employed  to  keep  Intact  still-valid  proofs  1 he  methods  of  Section  4 8 separate  out  all  affected 
proofs,  then  proofs  of  their  affected  subgoals  are  redone  via  the  prover. 

Proving  parts  of  formulas.  The  prover  decomposes  formulas  into  a series  of 
.suhgoals,  each  of  which  can  be  proved,  deferred  until  later,  or  assumed  with  justification.  This 
allows  proofs  to  be  done  piecewise  rather  than  all  at  once.  For  example,  the  user  can  do  part  of 
a prtrof,  then  temporarily  discontinue  it,  then  resume  It  later  without  having  to  redo  any 
subprcKifs  that  remain  valid.  Providing  for  this  kind  of  evolutionary  proving  is  Important 
because  difficult  propositions  that  cannot  be  e.stablished  automatically  are  often  more 
conveniently  (or  perhaps  out  of  necessity!)  proved  over  a period  of  time. 

The  ability  to  defer  or  assume  subgoals  Is  a valuable  addition  to  one’s  proof 
repertoire.  The  defer  command  Is  useful  when  the  user  wants  to  think  more  about  what  is 
needed  to  complete  the  current  proof  and  go  on  to  others,  yet  retain  already-completed  parts  of 
the  proof.  The  assume  command  Is  useful  when  the  user  secs  the  obvious  truth  of  a formula 
and  wishes  to  terminate  Its  automated  proof  and  when  the  prover  Is  unable  to  draw  the 
Inferences  necessary  to  complete  the  proof,  but  the  user  Is  able  to  prove  it  by  hand. 


I 

I 

1 
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These  features  complicate  part  3 of  the  DVM-prover  Interface.  The  prover,  upon 
concluding  the  proof  process,  must  convey  to  the  DVM  what  happened.  The  Information 
transmitted  varies  In  amount  and  kind  according  to  what  transpired  during  the  proof, 
examples  of  what  the  DVM  needs  to  know  are.  what  has  been  proved,  what  subgoals  are 
assumed,  what  subgoals  are  deferred,  what  their  names  are,  what  needs  to  be  saved  to  resume 
deferred  proofs,  and  what  properties  were  used  where.  The  DVM  assimilates  all  this 
information  to  determine  things  like  the  status  of  the  attempted  proof  and  the  Impact  of  this 
status  on  the  overall  problem. 

Part  1 of  the  interface  also  becomes  more  complex.  It  must  now  Initiate  proofs  of 
deferred  subgoals  as  well  as  original  proofs  and  reproofs.  As  with  reproofs,  the  DVM  brings 
together  the  needed  information  that  was  previously  collected  by  the  prover.  Fitting  proofs  of 
deferred  subgoals  Into  the  overall  proof  structures  is  much  like  the  problem  of  reproving 
subgoals.  The  only  difference  is  that  deferred  subgoals  do  not  have  any  prior  substitutions. 
The  prover  currently  handles  deferred  proofs  just  like  reproofs.  For  the  subsumption  test  to 
succeed,  proofs  of  deferred  subgoals  cannot  yield  any  substitutions  that  need  to  be  used 
elsewhere  in  the  overall  proof. 

Adding  new  facts.  Instead  of  adding  all  known  problem-domain  facts  (or  basis 
properties)  at  the  beginning  of  proofs,  individual  facts  are  added  when  needed  during  proofs. 
Needed  facts  may  already  be  part  of  the  collection  on  known  facts  or  added  anew.  Thus,  the 
user  can  gradually  build  up  a body  of  facts  that  describe  a particular  domain,  and  selectively 
apply  individual  ones.  Adding  facts  only  when  needed  has  long  been  the  policy  of  the  prover 
[Bledsoe  75].  The  interfaces  that  incorporate  this  capability  into  the  overall  system  are  new. 

The  scenario  for  adding  previously-undefined  facts  to  proofs  is  as  follows. 

Prov«r->  Use  lemma 

Enter  lemma  . . . 

* ALL  LtINT.  ALL  P;INT_ARRAY. 

* L IN  fl  .NI  ->  VALUE_OF_  MAX(P.L.Lt  « PfLlt 

Lemma  added  ...  Us  name  is  LEMMA*  1 

"Prover->"  is  the  prover’s  prompt  and  "<•"  Is  the  translator’s  prompt.  The  typed  lemma  is 
parsed  and  type-checked  within  the  context  of  the  overall  problem.  Value_of_max,  for 
example.  Is  checked  for  the  correct  number  and  types  of  arguments.  SID  assigns  the  name 
LEMMAel  for  subsequent  reference.  The  user  next  requests  a display  of  the  current  theorem. 
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Prov«r“>  Print  Theorem 

HI.  LI  in  [I  .N]  >>  VALUE_OF_MAX(P|,  L|,  LI)  * P|[L|] 

H2.  K-l 
— > 

Cl.  VALUE_OFJwlAX(B,  I,  1)  » B[l] 

l.EMMA*)  has  been  skolemlzed  and  added  as  hypothesis  HI.  Identifiers  containing  the 
symbol  "I"  are  skolem  variables. 

Transparent  to  the  user  In  this  scenario,  as  In  many  others,  Is  the  large  amount  of 
Intra-system  Interfacing  needed  to  carry  out  this  request.  Adding  a new  lemma  Is  a two-step 
process,  entering  the  lemma  Into  the  system  and  then  skolemizing  It  for  addition  to  the  current 
theorem.  Accomplishing  these  tasks  requires  several  Interactions  among  the  prover,  DVM, 
translator,  and  data  base.  Reasons  for  these  Interactions  (all  of  which  are  coordinated  by  the 
DVM)  Include  the  need  to  access  and  update  the  symbol  table  for  type  checking  purposes  and 
the  need  to  name  and  store  the  lemma  in  the  data  base  for  subsequent  reference.  Figure  S-8 
Illustrates.  Arrows  indicate  flow  of  control. 

Bringing  already-defined  facts  to  bear  on  a proof  is  straightforward.  The  user 
simply  refers  to  the  desired  fact  by  name  and  it  is  automatically  added  to  the  current 
hypothesis. 

Expanding  deferred  specification  expansions.  The  notion  of  adding  basis 
properties  to  proofs  only  when  needed  is  carried  over  to  specifications.  VCs  may  contain  only 
references  to  specifications  of  called  programs  instead  of  the  specifications  themselves.  Then, 
complete  specifications,  or  parts  of  specifications,  are  expanded  automatically  or  interactively  as 
needed  during  the  proof. 

The  motivation  for  this  Is  the  need  to  limit  the  site  of  VCs.  VCs  are  often  quite 
large  and  bulky,  hindering  effective  u-w  analysis.  For  example,  some  VCs  that  arise  from 
concurrency  in  the  communications  processing  example  In  Appendix  A are  50  to  100  lines  long. 
L.imiting  their  size  significantly  aids  the  interactive  proving  process.  Therefore,  SID  defers  the 
expansion  of  specifications  from  called  programs  in  both  specifications  and  executable  code 
until  the  actual  proof  has  begun.  (SID  also  addresses  this  problem  by  simplifying  VCs  as  they 
are  generated.)  This  tends  to  reduce  the  size  of  VCs,  enhance  readability,  and  keep  them  in 
terms  of  user-defined  abstractions. 

Deferred  specification  expansions  can  be  expanded  as  either  uninstantiated 
hypotheses  or  instantiated  definitions.  The  function  IsPerm  is  used  in  Illustrating  how 
specifications  are  added  as  additional  hypotheses. 
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Enter  Lemma  J 


User  types  "Add  Lemma"  to  prover 


Provor  calls  OVM  to  got  lemma 

OVM  calls  translator  to  read  lemma  from  terminal 

I ranslator  calls  OVM  to  get  information 

OVM  retrieves  information  from 
symbol  table  in  data  base 

OVM  returns  type  information  to  translator 


Skolemize  Lennia  J 


Translator  returns  lemma  to  OVM  which  names  and  stores 
it  in  the  data  base 

OVM  returns  lemma  to  prover 


'Prover  calls  OVM  to  declare  identifiers  during  sKolemization 
OVM  updates  symbol  table  in  data  base 

1/ 

OVM  returns  declared  identifier  to  prover 


Provor  types  the  prompt  “Prover->"  on  the  terminal 


Figure  3-8.  Interface  structure  for  adding  new  lemmas  during  proofs 
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function  l«P«rm(X,Ytint_array) : booloan  • 
begin 

•Kit  fassum* 

(all  Z:int_array,  lsParm(Z,Z)) 
and  (all  Z:inl_array, 

lsP*rm(X,Z)  and  ltP«rm(Z,Y)  ->  lsParm(X,Y))); 

•nd; 

Suppose  we  are  proving  the  following  theorem 

Prov«r->  Print  Theor«w 

HI  . N in  [K  .POSINF] 

H2.  K in  [2 ..N] 

H3. 1 in  [K*1..N]  ->  VALUE_OF_MAX|B,  I,  I)  « B(l] 

H4.  ISPERM(A,  B) 

H5.  K n*  I 
— > 

Cl.  ISPERM(A,  EXCHANGE(B,  LOCATION_OF_MAX(B,  I.  K),  K)) 

The  proof  requires  the  second  exit  property  of  IsPerm.  So  the  user  types 
Prov«r->  Us«  ItParm  2 

which  causes  the  desired  property  to  be  skolemlzed  and  added  to  the  theorem. 

Prov«r“>  Print  Theorarw 

HI.  ISPERM(X|,  Z|)  and  ISPERM(Z|,  Y|)  ->  ISPERM(X|,  Y|) 

H2  N in  [K.  POSINF] 

H3.  K in  [2 ..N] 

H4.  I in  tK*l..Nl  ->  VALUE_OF_MAX(B,  1, 1)  • BlIJ 
H5.  ISPERM(A,  B) 

H6  . K n«  I 
— > 

Cl.  ISPERM(A,  EXCHANGE(B,  LOCATION_OF_MAX(B,  I,  K),  K)) 

Hypothesis  HI,  with  skolem  variables  XI,  Yi,  and  Zi,  is  the  second  exit  property  of  IiPerm. 
For  a look  at  a definition  expansion,  consider  the  following  function: 
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function  lcExchanKod(A,B:int_array;  l,J:int):booloan  ■ 
bogin 

•xit  (assuino  ltExchangod(A,B,i,j)  iff 

( lin[I..N]  and  Jin[I..N] 
and  A(I]>B[J]  and  A[J>B[I]  ) ); 

•nd; 

Let  US  focus  on  one  hypothesis  of  a larger  theorem. 

Provor->  Print  Thoorom 

HI.  ISEXCHANGED(B,  EXCHANGE(B,  LOCATION_OF_MAX(B,  I,  K),  K), 

LOCATION_OF_AIAX(B,  1,  K),  K)  (3.3) 


Replacing  IsExchanged  by  its  definition  is  done  by  executing  the  following  command. 

Provor->  Expand  IsExehantad 

Hypothesis  HI  Is  replaced  by  four  hypotheses. 

Provor->  Print  Theorem 

Hi . LOCATiON_OF_MAX(B,l ,K)  in  [I ..N] 

H2.  K in  [I  ..N] 

H3.  EXCHANGE(B,  LOCATION_OF_MAX(B,  I,  K),  K)[K] 

« B[LOCATION_OF_MAX(B,  I,  K)] 

H4.  EXCHANGECB,  LOCATION_OF_MAX(B,  I,  K),  K) 

(LOCATION_OF_MAX(B,  I,  K)1 
-B[K1 


Hypotheses  HI-H4  are  obtained  by  instantiating  the  definition  of  IsExchanged  with  the 
arguments  in  (3.3).  That  is,  substitute  B for  A,  Exchange<B,  Location-of_max(B,l,K),K)  for  B. 
Locationjof-max(B,l,K)  for  Land  K for  J. 


Sometimes  these  expansions  are  triggered  automatically.  If  an  unexpanded  reference 
is  the  sole  hypothesis,  it  is  expanded  under  the  assumption  that  it  is  likely  to  be  needed  In  the 
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proof.  Also,  unexpanded  references  In  the  conclusion  are  expanded  so  they  can  be  proved. 
These  situations  often  are  not  present  when  the  proof  begins,  but  arise  during  the  proof  as  a 
result  of  the  proof  strategy  employed. 

Specification  expansions  are  not  always  deferred  until  proof  time.  It  Is  sometimes 
desirable  to  have  the  VC  generator  automatically  add  the  specifications  of  called  programs  to 
VCs,  Instead  of  Inserting  references  to  the  specifications.  For  example,  VCs  for  establishing 
entry  conditions  have  the  entry  condition  of  called  programs  fully  expanded  In  their  conclusion. 
Full  expansion  Is  also  done  when  proving  properties  of  concurrent  processes.  An  example  Is 
the  VCs  for  the  top-level  network  program  In  Appendix  A.  This  program  calls  procerses 
whose  block  specifications  are  fully  expanded  In  its  VCs.  This  Is  done  because  current 
experience  with  concurrency  proofs  using  SID  indicates  that  this  expansion  Is  nearly  always 
needed. 


3.4  The  System  Design 

Previous  sections  In  this  chapter  sketched  SID’s  overall  design,  described  Its 
designer/verifier’s  assistant,  and  discussed  its  incremental  capabilities  (along  with  the 
Interactions  Involved  In  accomplishing  them).  This  section  takes  a more  detailed  look  at  SID’s 
design,  focusing  on  Its  important  design  characteristics  and  Its  traditional  components. 

Figure  3-9  gives  a detailed  view  of  SID's  organization.  (The  assistant  was  broken 
down  in  Fig.  3-2.)  Solid  arrows  indicate  program  calls  visible  to  the  user  and  dashed  arrows 
indicate  calls  that  are  transparent  to  the  user.  The  impact  of  adopting  an  Integrated, 
Incremental  view  of  design  and  verification  is  evident  in  this  diagram. 

The  methods  of  Chapter  4,  which  are  implemented  In  the  DVM  part  of  the  assistant, 
encourage: 

• CfntraiitMtion  of  control.  To  perform  a particular  task,  the  DVM 
determines  what  work  needs  to  be  done  and  Invokes  the  appropriate 
program,  or  sequence  of  programs.  Tasks  are  Initiated  by  the  user  or  by  an 
Invoked  program. 

• CentrMlIittion  of  inforitmtion.  The  DVM  controls  all  data- 
transmission  links  in  the  system.  All  data  is  stored  In  a single  data  base 
directly  accessible  only  to  the  DVM. 

There  Is  one  exception  to  the  centralization  of  control  principle.  For  efficiency,  the  automatic 
simplifier  Is  called  directly  to  manipulate  Intermediate  data.  During  VC  generation,  for 
example,  the  simplifier  Is  called  every  time  an  assignment  statement  Is  traversed.  The 


J 


frequency  of  these  calls  suggests  using  a direct  Interface,  which  does  not  require  things  like  data 
reformatting  by  the  DVM. 


I Both  of  these  design  characteristics  have  important  benefits.  Centralizing  control 

n enables  the  methods  of  Chapter  4 to  screen  intended  operations  prior  to  their  execution  and 

thereby  prevent  things  like  generating  VCs  that  will  contain  type  conflicts.  It  also  enables  the 
DVM  to  coordinate  diverse  tasks.  Figure  4 8 illustrated  how  the  DVM  coordinates  the 
translator,  prover,  and  data  base  when  new  lemmas  are  added  during  proofs. 

C'.entralizing  information  enables  the  DVM  to  provide  a uniform  set  of  functions  for 
accessing  all  system  data.  These  functions  use  primitives  provided  by  each  component  for 
manipulating  the  data  they  produce  T he  translator,  for  example,  provides  symbol  table 
primitives  Components,  therefore,  can  access  information  without  knowledge  of  its  origin  or 
rejiresentation  details.  For  example,  the  prover  frequently  needs  type  information  to  ensure 
that  only  integer- valued  variables  are  entered  into  its  typelist  mechanism.  The  prover  obtains 
this  type  information  without  knowledge  of  the  translator  or  symbol  table  representation. 
Centralization  of  control  surfaces  here  too  because  the  assistant,  being  aware  of  context, 
e.stabllshed  the  appropriate  scope  In  the  symbol  table. 

The  discussion  below  describes  the  system  components  tied  together  by  the  assistant 
- the  translator,  VC  generator,  simplifier,  theorem  prover,  and  display  package  (not  In  Fig.  S-9). 
1 lie  focus  is  on  what  they  do  and  the  Impact  of  the  system  goals  on  their  design. 

'I'ranslator 

This  program  - developed  by  Wilhelm  Burger  - consists  of  a Gypsy  parser  and  type 
checker.  A code  generator  is  under  development.  The  translator  Is  table  driven  and  applies  to 
programs,  specifications,  and  basis  properties.  Its  parse  tables  are  generated  by  the  BOBSW 
system  (Burger  74].  Diagnostics  are  given  In  the  event  of  syntactic  or  type  errors.  Processed 
entitles  that  either  have  no  errors  or  have  only  type  errors  are  stored  In  the  assistant’s  data  base 
for  future  reference,  whereas  entities  containing  syntax  errors  are  not. 

1 he  Impact  of  the  methods  of  Chapter  4 on  the  overall  design  of  the  translator  is 
twofold.  First,  the  translator.  In  addition  to  having  and  entry  point  for  parsing  and  type 
checking,  also  has  an  entry  point  for  type  rechecking.  All  programs,  specifications,  and  basis 
properties  can  be  rechecked.  What  entitles  to  recheck  and  when  to  recheck  them  is  decided  by 
the  methods  of  Chapter  4.  Second,  all  type  checking  is  done  In  the  context  of  the  overall 
problem  as  represented  In  the  assistant’s  data  base. 
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Verification  Condition  Generator 

This  program  --  developed  by  Rich  Cohen  - serves  the  twofold  purpose  of 
generating  VCs  and  of  generating  a record  of  the  statements  Involved  In  the  generation  of  each 
VC.  The  proof  methodologies  Implemented  are  the  conventional  inductive  assertion  method 
[Floyd  67],  and  the  data  abstraction  and  concurrency  proof  techniques  described  in  Good  [771 

The  importance  of  limiting  the  sire  of  VCs  to  enhance  user  analysis  has  been 
discussed.  The  VC  generator  addresses  this  problem  in  two  ways: 

• Incremental  simplification.  The  VC  generator  uses  the 
automatic  simplifier  to  simplify  VCs  as  they  are  generated.  This  eliminates 
much  of  the  unnecessary  clutter  and  allows  mechanical,  propositional 
Inferences  (sometimes  resulting  in  logical  truths)  to  be  made  before  the  VCs 
are  displayed  to  the  user. 

• Defer  specification  expansions.  Only  references  to  some 

specifications  of  called  programs  are  inserted  in  VCs,  Instead  of  the 
specifications  themselves.  Section  3.3  gives  examples  and  shows  how  such 
references  are  expanded  during  proofs. 


Simplifying  during  VC  generation  has  potential  drawbacks  because  the  relationship 
between  VCs  and  the  statements  Involved  in  their  generation  may  be  obscured.  When  a proof 
attempt  fails,  this  correspondence  is  needed  to  determine  If  there  Is  an  Inconsistency  between  the 
program  and  its  specifications.  This  is  sometimes  easier  with  unsimpllfied  VCs.  The  VC 
generator  responds  to  this  Issue  by  recording  the  sequence  of  statements  used  in  the  generation 
of  each  VC  along  with  some  annotations.  1 he  user  may  have  these  annotated  paths  displayed 
in  parallel  with  VC  generation,  or  simply  request  them  later  as  needed.  The  need  for  these 
commentaries  Is  amplified  in  SID  because  of  complications  Involved  in  verifying  data 
abstractions  and  concurrency. 


Automatic  Simplifier 

This  program  simplifies  log;(al,  limited  relational,  and  arithmetic  expressions.  It  has 
a built-in  knowledge  of  the  propositional  calculus  and  is  fully  automatic.  The  VC  generator 
uses  It  to  simplify  VCs  as  they  are  generated,  and  the  theorem  prover  uses  It  to  simplify 
formulas  added  during  proofs.  1 he  philosophy  behind  the  simplifier  is  to  perform  efficient, 
straightforward  manipulations  without  Interaction  before  Invoking  the  more  powerful 
capabilities  of  the  interactive  theorem  prover. 
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Since  Its  original  use  In  the  verification  system  of  Good,  et  al.  [75],  Don  Good  made 
extensions  it  to  handle  rational  division,  various  symbolic  state  manipulation  capabilities 
needed  to  accommodate  the  VC  generator,  and  built-in  Gypsy  operators  for  manipulating 
things  like  sequences. 


Interactive  Theorem  Prover 

The  interactive  theorem  prover  Is  a variation  of  an  already  highly  developed 
program  originally  developed  as  part  of  the  Automatic  Theorem  Proving  Project  at  UT  Austin 
(see  Bledsoe  and  Tyson  {75]).  It  is  a natural  deduction  system  (i.e.,  a Gentzen-like  system  as 
opposed  to  a "less  natural’  system  such  as  resolution)  that  proves  theorems  by  subgoaling 
(splitting),  matching,  and  rewriting.  Its  handling  of  certain  formulas  from  Presburger 
arithmetic  {Bledsoe  75]  and  proofs  by  cases  makes  it  particularly  effective  in  verification  {Good, 
et  al.  75].  Mabry  Tyson  augmented  this  prover  in  several  ways  for  use  in  SID. 

User  Interface.  The  prover’s  command  structure  was  reworked  foi-  compatibility  with  the 
assistant’s.  The  prover  and  assistant  use  the  same  command  scanner  (also  written  by  Mabry 
T yson)  so  that  user  commands  are  handled  uniformly  at  all  interaction  points.  Unlike  the 
assistant,  the  prover  does  not  offer  suggestions,  nor  docs  It  answer  English  queries. 

Additional  Information.  Facilities  for  handling  deferred  specifications  and  using 
properties  from  the  assistant’s  data  base  were  added.  Examples  of  both  are  in  Section  S.S. 

Proof  presentation.  Since  successful  proofs  may  depend  upon  properties  that  incorrectly 
describe  the  domain,  easily-understandable  records  of  proofs  (displaying  how  properties  are 
used)  are  Important  as  documentation  for  verifications  to  be  credible.  Seeing  how  properties 
arc  used  Is  important,  for  example,  because  Individual  properties  that  appear  to  accurately 
characterize  the  domain  may  subtly  Interact  during  a proof  to  cause  unintended  Inferences. 
Thus,  the  prover  collects  a detailed  record  of  proofs  that  makes  explicit  both  built-in  and  user- 
supplied  assumptions.  An  Initial  version  of  a dual-mode  display  facility  is  available  for 
viewing  these  proofs.  The  user  has  the  option  of  interactively  directing  presentations  by 
requesting  the  desired  amount  of  detail  at  selected  steps,  or  of  having  a completely  automatic 
presentation  by  specifying  Initially  the  amount  of  detail  desired  throughout. 

Proof  Interruption.  The  user  can  direct  the  prover  to  abort,  assume,  or  defer  proofs. 
The  abort  command  Is  useful,  for  example,  when  the  user  sees  that  he  Is  trying  to  prove  a false 
theorem  and  wishes  to  terminate  the  search.  Section  S.S  discusses  the  assume  and  defer 
capabilities. 
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Display  Package 


Dwight  Hare  developed  a set  of  routines  for  formatted  printing  of  data,  Including 
programs,  specifications,  and  basis  properties.  Data  is  translated  from  its  internal  prefix  form 
to  formatted  Infix.  For  example,  the  lemma  represented  In  prefix  as 

(ALL  0 

(TYPREF  INT_J^RRAY) 

(ALLR 

(TYPREF  INT) 

(ALL  S 

(TYPREF  INT) 

(IMP  (AND  (AND  (IN  R (RANGE  I N))  (IN  S (RANGE  1 N))) 

(LT  (FUNCTION  VALUE_0F_MAX  D R S) 

(ARRAY  D (PLUS  S 1)))) 

(EQNUM  (FUNCTION  VALUE_0F_MAX  D R (PLUS  S I)) 

(ARRAY  D (PLUS  S I ))))))) 


Is  displayed  to  the  user  as 

all  D : INT_ARRAY, 

all  R,  S : INT,  R in  1 1 ..N]  and  S in  1 1 ..N) 

and  VALUE_0F_MAX(D,  R,  S)  < D[SMJ 
->  VALUE_0F_MAX(D,  R,  S«l)  « D[S»11 

Options  are  available  for  varying  Indentations  and  mixing  upper  and  lower  case.  This 
example  has  keywords  In  lower  case.  Several  components,  especially  the  assistant.  Interface  with 
this  package. 


3.5  Implementation  Details 

SID  is  entirely  Lisp  based,  completely  compiled,  and  runs  on  a PDP-IO  computer 
under  TOPS  at  The  University  of  Texas  at  Austin.  Most  of  the  system  is  written  In  Reduce 
[Fleam  71},  the  rest  is  written  directly  in  UCI  Lisp. 

When  designing  and  verifying  programs  like  the  sorting  example  or  the  message 
switching  network  in  Appendix  A,  SID  occupies  approximately  I86K  of  core.  This  amount 
includes  the  Lisp  system;  the  Reduce  translator;  all  of  the  programs,  tables,  and  data;  and 
enough  working  free  storage  to  handle  complex  manipulations.  Figure  5-10  summarizes  how 
memory  is  used.  Figure  5- 1 1 details  the  memory  requirements  of  SID’s  compiled  code,  breaking 


down  memory  into  binary  program  space  (area  for  compiled  functions  and  arrays),  free  storage 
(areas  for  Lisp  nodes),  and  full  word  space  (area  for  print  names  and  numbers).  Figure  $-12 
summarizes  the  memory  used  by  the  supporting  software. 


SID’s  code 

108 

Software  support 

48 

Working  Storage 

15 

Data  base  for  sort 

(network) 

10 

(16) 

TOTAL 

181K 

(I86K) 

Figure  3-10.  Memory  requirements  for  running  SID 
in  thousands  of  PDF- 10  words 
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Binary  program  space 

assistant  12 

translator  (includes  tables)  11 

VC  generator  6 

interactive  theorem  prover  16 

automatic  simplifier  7 

display  package  6 

Free  storage  24 

Ful I word  space  8 

Global  initializations  18 

TOTAL  108K 


Figure  3-11.  Memory  requirements  for  SID's  compiled  code 


l.Isp  system 

Reduce  (without  algebraic  package) 

TOTAL 


85 

18 

48K 


Figure  3-12.  Memory  requirements  for  supporting  software 
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CHAPTER  4 


METHODOLOGY  FOR  RESPONDING  TO  CHANGES 


This  chapter  first  overviews  the  methodology,  then  details  the  algorithms  and  the 
underlying  data  base  they  manipulate.  The  term  "pi'ogram  unit"  is  used  to  refer  to  a program 
and  its  specifications. 


4.1  Preview  of  the  Methodology 

This  section  gives  a preliminary  overview  of  the  methods  for  dealing  with  changes 
to  programs,  specifications,  and  basis  properties.  Both  the  general  approach  and  Important 
characteristics  of  the  methods  are  discussed. 


Key  Ideas 

Designing  and  verifying  programs  involves  developing  a highly-interrelated 
collection  of  several  kinds  of  information,  including  programs,  specifications,  VCs,  basis 
properties,  and  proofs.  Initially,  the  methods  are  best  understood  by  considering  only  some  of 
this  information  and  a few  ways  in  which  It  is  related.  The  sorting  program  of  Section  1.2 
again  is  used  for  illustrative  purposes. 

Figure  4-1  gives  the  final  version  of  the  sorting  program  accompanied  by  the  lemmas 
u.sed  in  Its  verification.  The  discussion  below  refers  to  the  line  numbers  to  the  left  of  the 
li.sting,  which  are  not  a part  of  the  program  or  lemmas.  From  this  Information,  the  methods 
build  the  cyclic  graph  structure  In  Fig.  4-2  to  describe  calling  relationships.  Arrows  in  Fig.  4-2 

indicate  direct  calls  in  Fig.  4-1.  For  example,  Exchange.sort  calls  Itself  on  line  9, 

I.ocation_of_max  on  line  19,  Value_of_max  on  line  10,  Exchange  on  line  19,  and  IsPerm  on 
line  1 1.  Figure  4-2  omits  data  definitions  because  they  are  handled  differently  from  functions. 

Suppose  that  the  definition  of  Location_of_max  is  altered  by  interchanging  lines  48 

and  49.  What  are  the  effects  of  this  change?  Figure  4-8  gives  a first  approximation  of  the 

answer,  excluding  those  functions  that  do  not  directly  or  indirectly  call  Location-of_max  from 
consideration.  This  approximation  is  refined  by  observing  that  Exchange-sort  cannot  be 
affected  because  lines  48  and  49  are  In  a part  of  Location_of_max  that  is  not  visible  to  Us 
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1 const  n:int  ^ pending; 

2 

3 typo  int_arr8y  = array  ((l..n])  of  int; 

4 

5 function  Exchange_sort(A:int_array):int_array  ■ 

6 begin 

7 entry  N go  1 ; 

8 exit  (all  hint, 

9 lin[l..N]*>  Exchange_sort(A)[l} 

10  e Value_of_tnax(Exchango_aort(A),l,l)) 

I 1 and  lsPerm(A,  Exchango_tort(A)); 

I 2 var  B:int_array  A; 

1 3 var  K:int  ;=  N; 

I 4 keep  K in  [I  ..N]; 

1 5 loop 

16  assert  (all  hint,  I in  [K*I..N]  ->  B[l]  e Value_of_max(B,l,l)) 

17  andKin[l..N]  and  lsPerm(A,B); 

18  if  K = I then  leave  end; 

19  B :=  Exchange(B,Location_ol_max(B,i,K),K); 

20  k:=K-l; 

21  end; 

22  result  :<  B; 

23  end; 

24 

25 

26  function  Valuo_of_fnax(A:int_array;  l,J:int):int  « 

27  begin 

28  exit  ( assume  ( all  K:int, 

29  k in  [I ..J]  and  I in  [1  ..N]  and  J in  [1  ..N] 

30  ->  A[k]  le  Value_of_max(A,l,J)  ) 

31  and  ( all  l,m:int, 

32  I in  [I..J]  and  m in  [I..J]  and  I in  [1..N]  and  J in  [1..N] 

33  ->  Value_of_max(Exchange(A,l,m),l,J)  ■ 

34  Value_ol_max(A,l,J)  ) ); 

35  end; 

36 


Figure  4-1 . Final  version  of  sorting  program  and 
lemmas  used  in  its  verification 
^continued  on  next  page) 


Page  65 


37  (unction  Localion_ol_max(A:ini_array;  l,J:int):int  ■ 

38  b«|>in 

39  antry  I in  [I..N]  and  J in  [1..N]  and  I le  J; 

40  exit  Location_o(_max(A,l,J)  in  [I.J] 

41  and  A[Location_ol_max(A,l,J)]  « Value_ot_jnax(A,lrl)t 

42  var  K:int  :■  I; 

43  keep  I le  J and  I in  [1  -N]  and  J in  [1  ..N]  and  K In  [I ..N]; 

44  result  :e  I; 

45  loop 

46  assert  A[resull]  * Valuo_o(_niax(A,l,K) 

47  and  result  in  [I  .K]  and  K in  [I..J]; 

48  if  K ge  J then  leave  end; 

49  K:>K*1; 

50  if  A[resull]  < A[k]  then  result  :■  k end; 

51  end; 

52  end; 

53 

54  function  Exchan|'e(A:inl_array;  l,J:int):inl_array  ■ 

55  begin 

56  entry  I in  [1  ..N]  and  J in  [1  ..N]; 

57  exit  (all  k:[l..N], 

58  k ne  I and  k ne  J •>  Exchange(A,l,J)[k]  ■ A[k]  ) 

59  and  lsExchanged(A,Exchange(A,l,J),l,J) 

60  and  lsPerm(A,Exchange(A,l,J)); 

61  result  A; 

62  result[l]  :*  A[J]; 

63  result[J]  :■  All); 

64  and; 

65 

66  (unction  lsExchanged(A,B:int_array;  l,J:int):boolean  ■ 

67  begin 

68  exit  (assume  lBExchanged(A,B,i,j)  ifl 

69  ( lin[l..N]  and  Jin[l..N] 

70  and  A[I]>B[J]  and  A[J]>B[I]  ) ); 

7 1 and; 

72 

Figure  4-1 . (cont'd)  Final  version  of  sorting  program  and 

lemmas  used  in  its  verification  (cont'd.  on  next  page) 
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(unction  lsP«rm(X,Y:inl_array)  : booloan  ■ 
boRin 

•xi(  (assume 

(all  Z:inl_array,  lsP«rm(Z,Z)) 
and  (all  Z:int_array, 

lsPerm(X,Z)  and  lsPerm(Z,Y)  ->  lsPorm(X,Y))); 

•nd; 


LEMMAal  is 
all  L : INI, 

all  P : INT_ARRAY,  L in  [1..N]  ->  VALUE_OF_MAX(P,  L,  L)  ■ P(Ll 

LEMMAaZ  is 
all  D : INT_JVRRAY, 

all  R,  S : INT,  R in  [1..N]  and  S in  [I..N] 

and  VALUE_OF_MAX(D,  R,  S)  < D[S»I1 
->  VALUE_OF_MAX(D,  R,  S»l)  « D[S»11 

LEMMAa3  is 
all  D*1  : INT_>VRRAY, 

all  R«l,  sal  : INT,  Ra|  in  [1..N]  and  Sal  in  [1..N] 

and  VALUE_OF_MAX(Dal,  Ra|,  Sal)  go  Dal[Sal*|] 
->  VALUE_OF_MAX(Dal,  Ral,  SalO) 

« VALUE_OF_MAX(Dal,  Ral,  $•!) 

LEMMAa4  is 
all  L,  M : INT, 

all  P : INT_>\RRAY,  L in  [l.N]  and  M in  [1..N] 

->  ISPERM(P,  ALPHA(ALPHA(P,  L,  P[M]),  M,  P[L])) 


Figure  4-1.  (cont'd.)  Final  version  of  sorting  program  and 
lemmas  used  in  its  verification 


Figure  4-2.  Calling  relationships  in  Fig.  4-1 
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callers.  But  Excbange_sort  can  be  affected  by  a change  to  (or  changes  that  affect)  the  header  of 
L.ocation-of_inax  on  line  37.  From  these  simple  observations  comes  a fundamental  principle  - 
changes  have  global  effects  only  through  externally-vlsible  parts  of  program  units;  conversely, 
changes  to  other  parts  have  only  local  effects.^ 

Distinguishing  between  external  and  internal  parts  of  program  units  is  usually  only 
the  first  step  in  determining  the  effects  of  changes.  Suppose  that  the  header  of  IsExchanged  on 
line  66  is  changed  to 

function  lsExch«nKod(A,B:int_arr«y;  l:int):boolean  ■ 

The  argument  J has  been  deleted,  changing  the  number  of  arguments  to  IsExchanged  from 
four  to  three.  Figure  4-1  gives  a first  approximation  of  the  affected  substructure,  excluding 
IsPerm  and  Lemma«4  from  consideration.  Applying  the  same  "Intcrnal/externar  principle  as 
before  yields  a duplicate  of  Fig.  4-4.  The  Initial  approximation  is  not  refined.  One  effect  of 
changing  the  number  of  arguments  to  IsExchanged  is  a type  mismatch  In  the  exit  specification 
of  Exchange  (line  59),  which  can  be  exported  for  use  In  the  proof  of  callers  of  Exchange.  This 
exit  specification  can  be  exported  to  Exchange_sort  via  several  routes.  Including  an  indirect  one 
through  Value_of_max  (because  the  exit  specifications  of  Value-of-max  call  Exchange  on  line 
33  and  Exchange-Sort  calls  Value_of_max  on  line  10). 

There  are  several  more  ways  In  which  the  propagation  of  the  effects  of  changes  are 
constrained.  One  way  is  by  knowledge  of  where  properties  have  been  used.  Figure  4-5 
describes  where  the  exit  specifications  of  Exchange  and  IsExchanged  have  been  used.  These 
descriptions  enable  the  methods  to  reduce  the  substructures  In  Fig.  4-4  to  the  one  in  Fig.  4-6. 
Other  constraints  detailed  later  include  rules  for  deciding  when  changes  to  previously-used 
specifications  have  no  effects. 

It  Is  not  enough  to  know  only  what  programs  are  affected  by  changing  the  number 
of  arguments  to  IsExchanged.  How  they  arc  affected  Is  also  important.  Two  general  kinds  of 
consistency  are  introduced  for  classifying  the  effects  of  changes.  Design  consistency  refers  to  the 
syntactic  and  type  consistency  of  programs,  specifications,  and  basis  properties.  Verification 
consistency  refers  to  the  correctness  of  VCs  (eg.,  that  VCs  contain  no  type  errors  and  reflect 
ctianges  In  the  asscKiated  programs  and  specifications)  and  to  the  use  of  specifications  and  basis 
properties  In  proofs  (e.g.,  that  no  proofs  depend  on  design  Inconsistent  properties  and  that  the 
needed  logical  relationships  hold  between  intermediate  and  final  versions  of  properties  used  in 
proofs).  Applying  these  classifications  to  the  programs  In  Fig.  4-6  yields  Fig.  4-7.  IsExchang^ 
is  design  inconsistent,  for  example,  because  of  a mismatch  In  the  number  of  arguments  between 
its  recursive  call  on  line  68  and  its  changed  header.  Exchange  has  a similar  type  mismatch  on 


t 


Changes  to  external  parts  of  units  may  also  have  local  effects,  as  will  be  shown  later. 


Figure  4-4.  Firsf  approximaHon  of  substructure  affected  by  a change  to  IsExchonged 


Exchange 


Exchange.sort 


Exchange_sort#7 
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Used  In  Proving 


IsExchanged 


Exchange  Exchange_sorf 


Exchange#!  Exchange_sorf#7 


Used  In  Proving 


Figure  4-5.  Addifional  descriptions  showing  where  the  exit  specifications 
of  Exchange  and  IsExchanged  have  been  used 
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Figure  4-6.  Affected  programs  within  the  subsfrucfure  of  Fig.  4-4 


Figure  4-7.  Kinds  of  effects  on  the 


programs  of  Fig.  4-6 
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line  59  and  also  a verification  Inconsistency  because  this  mismatch  Is  In  Exchangeal,  as  shown 
in  Fig.  4-5(b).^  Only  the  verification  of  txchangc,sort  is  affected.  1 his  is  due  to  Its  use  of  the 
exit  specifications  of  Exchange  and  IsExchanged  (which  now  have  a type  mismatch)  in  the 
proof  of  ExchangC-Sort«7.  as  shown  In  Fig.  4-5. 

In  addition  to  determining  the  effects  of  changes,  the  methodology  must  also  ensure 
that  all  inconsistencies  are  eventually  resolved  and  enforce  any  constraints  intermediate  ones 
might  imply.  This  involves  things  like  not  allowing  VCs  to  be  regenerated  for  Exchange  In 
Fig.  4-7  or  its  second  exit  specification  to  be  used  In  proofs  until  the  type  mismatch  on  line  59  is 
corrected. 

In  summary,  the  effects  of  changes  are  determined  by  exploiting  useful  constraints  on 
how  objects  in  the  domain  interact  with  one  another.  Previous  examples  illustrated  the  utility 
of  several  constraints  - calling  relationships,  external  and  Internal  parts  of  program  units,  and 
uses  of  specifications  - In  curtailing  the  propagation  of  the  effects  of  changes.  The  less  the 
propagation,  the  more  previous  work  that  is  kept  intact.  I'hese  and  other  important  constraints 
are  explained  In  detail  In  the  remaining  sections  in  this  chapter. 

Characteristics  of  the  Methodology 

Allows  temporMry  inconsistencies.  Temporary  design  and  verification 
inconsistencies  are  allowed  In  intermediate  problem  states.  1 his  affords  several  flexibilities. 
For  example,  top-down  design  Is  enhanced  by  allowing  calls  to  as  yet  undefined  programs. 
These  called  programs  can  be  (partially)  defined  whenever  convenient,  thereby  eliminating 
prior  design  Inconsistencies.  A common  verification  inconsistency  arises  when  proofs  depend 
on  specifications  that  now,  as  a result  of  a change,  contain  a type  error.  Later,  the  user  may 
wish  to  undo  the  change,  reinstating  the  validity  of  the  proofs. 

Applies  to  any  of  several  strategies.  The  methods  apply  to  any  of  several 
program  design  and  verification  strategies.  Programs  and  specifications  are  constructed  using  a 
top  down,  bottom-up,  or  mixed  design  strategy  and  the  verification  is  carried  out  in  parallel  or 
any  desired  order.  Changes  are  made  whenever  convenient. 

Adapts  to  a class  of  languages.  Although  applied  here  to  Gypsy,  the  methods  are 
Intended  for  use  with  other  Pascal-like  programming  languages  and  their  related  proof 
methods.  A set  of  language-dependent  functions  is  coded  for  the  language  of  interest.  These 


^ Additional  knowledge  Is  used  to  determine  that  IsExchanged  does  not  have  a 
verification  Inconsistency.  Namely,  it  is  for  specification  purposes  only  and,  therefore,  does  not 
have  VCs. 
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functions  are  called  by  algorithms  which  remain  essentially  Intact  for  different  languages  and 
proof  methods.  Also,  some  table-driven  algorithms  require  a description  of  certain 
interrelationships  between  specifications  and  proof  methods. 

Delays  consistency  checking  until  necessary.  The  scheme  for  resolving 
inconsistencies  Is  based  on  the  following  premise  - trying  to  resolve  Inconsistencies  when  they 
occur  is  often  fruitless  since  a sequence  of  changes  is  often  made,  the  last  of  which  resolves  all 
intermediate  inconsistencies.  1 he  methods,  therefore,  simply  note  that  consistency  checks  need 
to  be  made,  then  perform  the  needed  checks  In  response  to  user-initiated  operations.  That  is,  it 
automatically  makes  those  checks  necessary  to  guarantee  a consistent  state  change. 

Generally  avoids  case-by-case  analysis.  The  methods  adopt  the  policy  of 
treating  changes  to  externally  visible  parts  of  programs  as  if  they  always  affect  callers,  rather 
than  analyzing  the  exact  change  on  a case-by-case  basis.  This  strategy  is  much  simpler  than 
doing  case-by-case  examinations.  For  example,  it  simplifies  the  Interface  between  the  methods 
and  the  type  checking  program.  Rather  than  communicating  via  sophisticated  error- 
classification  schemes,  a boolean-valued  Interface  is  all  that  is  needed  It  appears,  however,  that 
case-by-case  analysis  is  useful  In  some  situations,  especially  with  the  aid  of  a knowledgeable 
editor  such  as  the  one  in  Yonke  [75].  Identifying  the  classes  of  changes  that  should  be  dealt 
with  individually  is  an  area  for  future  research. 

Some  uses  of  case-by-case  analysis.  Changes  to  basis  properties  and 
specifications  are  dealt  with  on  an  individual  basis.  Although  the  above  discussion  ruled  out 
this  approach  for  the  analysis  of  changes  to  programs.  It  is  viable  for  Isolating  the  exact 
impact  of  changes  to  formulas.  Typically,  such  changes  may  affect  several  verifications.  In 
practice,  it  can  often  be  shown  that  at  least  parts  of  the  verification  are  unaffected  - thereby 
avoiding  unnecessary  reverification.  The  methods  detect  such  situations  by  making  logical 
"comparisons"  between  a formula  and  its  revised  version  when  neither  contains  a type  error. 

Assumptions.  The  methods  assume  that  type  checking  of  programs,  specifications,  and 
basis  properties  is  done  at  compile  time  and  that  programs  do  not  have  side  effects  except 
through  explicitly  declared  var  parameters.  Gypsy  eliminates  side  effects  by  disallowing  non- 
local variables  and  by  controlling  interactions  among  concurrent  processes.  Concurrent 
processes  communicate  by  performing  send  and  receive  operations  on  buffers. 

Notes  to  the  Reader 

While  studying  the  formalization  given  in  this  chapter,  the  reader  should  keep  in 
mind  that  although  algorithms  are  discussed  separately  by  topic,  they  are  highly  Interrelated 
and  should,  therefore,  be  viewed  collectively.  Also,  efficiency  is  sacrificed  for  simplicity 
throughout.  Before  explaining  the  algorithms.  Section  4.2  first  describes  (as  background)  the 
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underlying  data-base  structure  used  by  the  methods  and  notation  to  be  used  throughout.  Then, 
Sections  4 8 - 4.7  explain  the  methodology  as  it  applies  to  conventional  functions  and 
procedures,  and  to  concurrent  pnxess  definitions  in  Gypsy.  Specific  algorithms  and  the  data 
structures  they  manipulate  (In  addition  to  the  data  base)  are  detailed.  To  simplify  the 
presentation,  basis  properties  are  considered  separately  in  Section  4.8.  Section  4.9,  building  on 
the  established  framework,  explains  how  types  and  data  abstraction  mechanisms  are  handled. 

The  methods  are  formulated  to  allow  for  complete  expansion  of  specifications  from 
called  programs  during  VC  generation.  To  illustrate,  imagine  a hierarchy  of  specifications  in 
which  a lower-level  specification  contains  a type  conflict.  The  formulation  adopts  the 
conservative  view  of  expanding  all  these  specifications  in  VCs,  even  though  it  may  be  possible 
to  do  all  proofs  without  expanding  specifications  to  a depth  that  reveals  the  design 
inconsistency.  Section  4.10  describes  how  the  methods  were  tailored  for  use  in  SID  to  account 
for  this  possibility. 

Phrases  like  "X  contains  semantic  errors"  and  "X  is  semantically  Inconsistent"  refer  to 
those  aspects  of  semantics  handled  by  type-checking  programs  In  compilers.  This  Includes 
resolving  external  references  and  ensuring  that  program  calls  are  set  up  properly. 

The  convention  of  designating  changed  data  with  a prime  symbol  is  adopted 
throughout.  For  example,  a revised  version  of  unit  X is  referred  to  as  X’. 


4.2  Data-base  System 

This  section  describes  the  data  base  of  facts  (operated  on  by  programs  described  later 
In  this  chapter)  and  Its  accompanying  access  mechanisms.  Then,  notatlonal  abbreviations  for 
expressing  data-base  calls  are  introduced. 

I'he  Structure  for  Holding  Data 

Associated  with  every  program  unit  and  basis  property  is  a collection  of  related  data. 
A sample  Is  shown  in  Fig.  4-8,  which  gives  data  stored  about  Locatton_of_max  and  Illustrates 
how  the  data  Is  structured. 

SID  represents  such  structures  as  hierarchically-structured  lists  of  attribute/ value 
pairs  Attributes  are  atoms  and  values  are  atoms,  lists  of  atoms,  or  general  s-expressions.  The 
important  descendants  possible  for  each  program  unit  are  described,  with  subsequent 
di.scusslons  clarifying  their  meaning  and  use  Omitted  here  are  data-base  entries  for  describing 
data  definitions  (see  Section  4-9)  and  what  Information  Is  backed  up  when  changes  occur  (see 
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Sections  4-4  and  4-6).  Listed  below,  In  boldface,  arc  top-level  attributes  for  program  units, 

accompanied  by  a description  of  their  values.  The  atom  UnItName  refers  to  the  name  of  the 

program  unit  being  described. 

InternalRep  1$  the  internal  representation  of  UnItName  initially  generated  by 

the  translator.  Each  program  unit  is  stored  as  a single  entity  and 
programs  extract  different  parts  when  needed.  Terminals  are 
given  default  assignments  until  specific  data  is  available.  The 
default  value  of  "completely  undefined"  is  assigned  here  If  there  is 
data  about  UnItName  (eg.,  that  it  is  called  by  a lemma)  before 
any  part  of  its  definition  is  successfully  parsed. 

VCs  consists  of  VCnameivalue  pairs,  where  VCname  is  the  system- 

generated name  of  a VC  and  value  is  a list  of  three  possible  pairs 
whose  attributes  are  - InternalRep,  Used,  and  ProofUnIt. 
InternalRep  references  the  internal  form  of  the  VC;  Used  has  as  a 
value  the  names  of  the  basis  properties  used  in  the  proof  of 
VCname;  and  ProofUnit  Is  the  proof  structure  returned  by  the 
theorem  prover  after  attempting  to  prove  VCname. 

Status  is  the  current  status  of  UnitName.  Some  possible  values  of  Status 

are  "to  be  VC  generated",  "to  be  proved",  and  "partially  proved". 
Actually,  many  of  the  direct  descendants  of  UnitName  have  status 
values  for  ease  of  analysis,  updating,  and  responding  to  user 
requests.  Status  possibilities  for  a VC  include  "proved  in  theorem 
prover"  and  "proved  except  for  one  deferred  subgoal". 

SyniTab  is  the  local  symbol  table  for  UnitName  defined  by  the  type 

checker. 

Paths  consists  of  PathNameivalue  pairs,  where  PathName  is  the  name 

of  a program  path  whose  value  is  a path  produced  by  the  VC 
generator.  Paths  and  VCs  are  related  by  cross  references. 

CalIsFromInternals  contains  the  names  of  program  units  that  call  UnitName  in  their 

executable  text  or  internal  specifications. 

CalIsFromExternalSpecs  contains  the  names  of  program  units  that  call  UnitName  In  their 

external  specifications. 

CallsFromBasisProps  contains  the  names  of  the  basis  properties  that  call  UnitName. 

The  default  value  of  nil  in  Fig.  4-8  indicates  that  no  basis 
properties  call  Locatlon_of_max. 
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CheckSemantlcsFlag  Is  a boolean  flag  that  Indicates  whether  UnItNanae  potentially 

contains  type  errors.  The  value  of  false  In  Fig.  4-8  Indicates  that 
l.ocation.ofjnax  does  not  contain  type  errors. 

CheckVCsFlag  Is  a boolean  flag  that  Indicates  whether  the  VCs  for  UnItName 

are  potentially  Incorrect. 

CheckBasisFlag  Is  a flag/value  that  Indicates  if  the  verification  of  UnItName  Is 

potentially  Invalid  due  to  a change  to,  or  an  Inconsistency  In,  a 
basis  property.  The  value  of  this  flag,  when  set,  Is  the  names  of 
those  basis  properties  that  invalidate  UnItName’s  verification. 
1 hese  properties  are  associated  with  particular  VCs  via  the  Used 
attribute  under  VCs. 


Basis  properties  added  by  the  user  to  complete  a proof  are  Integrated  with  programs 
and  their  specifications  In  the  data  base.  An  example  of  how  they  are  stored  Is  seen  In  Fig.  4-9. 
Basis  properties  are  linked  to  the  verification  by  their  Usedln  attribute  and  by  the 
CheckBasisFlag  for  program  units,  and  to  the  design  by  the  CalIsFromBasIsProps  attribute  for 
program  units. 

InternalRep  Is  the  Internal  representation  of  the  basis  property. 

Usedln  is  a list  containing  each  UnitName  employing  this  basis  property  In 

Its  verification. 

CheckSemantlcsFlag  Is  a boolean  flag  as  defined  above. 

NotUsableFlag  Is  a boolean  flag  that  Indicates  If  the  property  can  currently  be  used 

in  proofs. 


Data  Manipulation 

There  are  three  types  of  data  base  calls  - Insertion,  retrieval,  and  deletion.  Insertions 
Into  the  data  base  are  made  by  the  call 

Insertfkey, attribute attribute,value) 

Insert  Is  used  both  to  add  new  data  Items  and  to  replace  existing  ones.  Insertions  Involve  two 
operations;  storing  the  new  data  Item  (replacing  the  old  data  Item,  If  necessary)  and  connecting 


Lemma#  1 


Figure  4.9  Data  about  Lemma#!  stored  In  the  data  base 
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the  new  data  item  to  its  parent.  The  key  field  contains  the  name  of  a program  unit  or  a buls 
property,  attributes  identify  the  desired  descendant  of  the  key,  and  the  value  field  contains  the 
new  data  item  to  be  stored.  Data-base  retrievals  and  deletions  are  made  by  the  calls 

Cct(key, attribute,  . . . ) 

I)elete(key, attribute, . . . ) 

Delete  removes  a data  item  and  all  of  its  descendants  from  the  data  base. 

l.et  us  digress  momentarily  to  consider  how  hierarchical  definition  structures 
(compared  to  the  flat  structure  of  Gypsy)  are  accommodated,  while  retaining  this  simple  data- 
base organization.  The  strategy  is  to  assign  a unique  name  to  each  unit  in  a hierarchy  (using, 
for  example,  consecutive  integers)  before  it  is  stored  in  the  data  base,  while  maintaining  a 
current  context  tree  and  name  mapping  which  together  represent  the  original  textual  nested 
structure.  This  scheme  does  not  affect  the  methods,  but  does  affect  data-base  calls  In  that  the 
key  field  Is  replaced  by  the  call: 


GetUnlqueName(key) 

GetUniqueName  is  a function  that,  depending  on  whether  or  not  the  "key"  Is  the  original 
name  of  a program  unit  or  a system-generated  name,  returns  the  corresponding  unique  Internal 
name  or  "key"  Itself,  respectively. 


Nntatlonal  Conventions 

In  stating  parts  of  the  methodology,  It  Is  often  necessary  to  specify  individual,  or 
sequential  instances  of  the  above  calls  on  the  data  base,  lb  shorten  the  expression  of  such 
calls,  the  convention  adopted  is  to  either  use  shorthand  for  the  actual  call  or  (when  obvious 
from  context)  omit  a formal  designation  altogether.  The  shorthand  convention  is  to  subscript 
an  attribute  with  the  key  itself. 

A few  example  manipulations  on  the  data  base  structure  in  Fig.  4-8  serve  to  illustrate 
the  kind  of  abbreviations  used  throughout.  The  phrase  "the  Internal  representation  of 
l.ocation_ofjmax"  and  the  subscripted  attribute  "lnternalRep[  pcation  of_max"  mean 

GeULocation_of_max,lnlernalR«p) 

The  phrase  "set  CheckSemantlcsFlag|  means 

lnsert(Location_of_max,ChaekSomanlicsFl8(’,lrue) 

whereas  a flag  is  reset  by  Inserting  the  value  false  A phrase  such  as  "add  Exchange  to  the 
CalIsFromInternals  attribute  of  Location_of_max"  is  equivalent  to 
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lns«rt(Loc«tion oi max.Cailsrromlnternals, 

cons(Exchang«,Get(Location_of_max,CallsFromlnternalt))) 

with  the  Lisp  operator  cons"  used  to  add  Exchange  to  the  appropriate  list. 


4.3  Defining  New  Programs  and  Their  Specifications 

1 his  section  studies  the  Impact  of  defining  new  program  units  on  the  overall  design 
and  verification  structure,  and  vice  versa.  Generally,  newly-defined  units  are  Inserted  into  an 
existing  data-base  structure.  The  methods  allow  for  a unit  to  be  called  prior  to  its  definition 
and  for  a new  unit  to  call  defined  or  undefined  units.  The  only  requirement  accompanying 
this  referencing  flexibility  is  that  units  must  be  successfully  parsed  before  they  arc  added  to  the 
data  base 


Key  Ideas  involved  in  handling  new  units  are  Illustrated  by  considering  a data  base 
that  contains  only  two  program  units: 

function  Exchango_cort(A:inl_8rray):int_array  « 
begin 


Exchangef . . . ) 


end; 


function  l*Exchanged{A,B:int_array;  l,J:int):boolGan  ■ 
begin 

exit  (assume  lsExchanged(A,B,i)  iff 

( I in  (I ..NJ  and  J in  (1  ..N] 
and  A[I]=B(J]  and  AlJ>B[l]  ) ); 

end; 

Observe  that  both  are  semantically  Inconsistent.  Exchangc_sort  has  an  unresolvable  external 
reference  because  of  Its  call  to  Exchange  and  IsExchanged  contains  a type  mismatch  in  its  exit 
specification  because  the  recursive  call  has  only  three  (instead  of  four)  arguments.  Suppose 
that  Exchange  is  now  defined  and  calls  IsExchanged.  Two  questions  arise; 
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• Glob  Ml  iwpMCt.  How  docs  Exchange  affect  Exchange-sort  and 
IsExchanged? 

• LocmI  ImpMct.  How  do  Exchange-sort  and  IsExchanged  affect 

Exchange? 

Regardless  of  how  Exchange  Is  defined,  it  cannot  Introduce  more  inconsistencies  In 
Exchange-Sort  or  IsExchanged.  Determining  the  local  impact,  however,  requires  knowing 
relationships  between  Exchange  and  IsExchanged.  For  example,  consider  what  happens  if  VCs 
are  generated  for  the  following  definition  of  Exchange: 

function  Exchan|;«(A:int_array;  l,J:int):int_array  ■ 
begin 

entry  I in  [I..N]  and  J in  [I..N]; 
exit  (all  k:[I  ..N], 

k no  I and  k no  J ->  Exchan{’o(A,l,J)[k]  « A[k]  ) 
and  IsExchangodfAiExchangotAiliJIil.J) 
and  lsPerm(A,Exchango(A,l,J)); 
rosull  A; 
rosult[l]  :■  A[J]; 
result[J]  :*  Atl]; 
end; 


The  single  VC  would  be  semantically  Inconsistent  because  it  would  contain  the  inconsistent 
exit  specification  of  IsExchanged.  The  methods  prevent  this  kind  of  occurrence. 

The  algorithm  for  defining  new  programs  and  specifications  uses  the  following 
functions  For  program  unit  X,  let 

InternalCallsTo(X) 

return  the  names  of  other  program  units  called  in  the  executable  body  or  internal  specifications 
of  X and 

ExternalSpecCallsTo(X) 

return  the  names  of  other  program  units  called  in  the  external  specifications  of  X.  Also,  let  the 
boolean-valued  function 

ScmanticaUyConsistent(X) 

be  a call  to  a semantic  checker  to  determine  whether  or  not  X Is  semantically  consistent.  This 
function  is  the  sole  Interface  between  the  algorithms  and  a semantic  checker. 
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The  algorithm  for  adding  a new  unit  consists  of  four  main  steps.  The  first  two  steps 
fill  in  the  necessary  global  cross  references.  Locally,  the  third  assigns  a status  value  and  the 
fourth  determines  If  any  flags  need  to  be  set  to  temporarily  override  the  status  setting. 

Algorithm  A.  For  a newly-defined  program  unit  X,  the  algorithm  Is  stated  as  follows: 

1.  For  each  Y In  InternalCallsTo(X),  add  X to  CallsFromlnternalsy. 

2.  For  each  Y in  ExternalSpecCallsTo(X),  add  X to  CalIsFromExternalSpecsY- 

3.  Set  Status^  to  "to  be  VC  generated". 

■la.  If  not  SemantlcallyConslstent(X),  then  set  CheckSemantlcsFlag^. 

•<b.  Otherwise,  If  there  is  a Y in  InternalCallsTo(X)  or  ExternalSpecCallsTo(X) 
such  that  CheckSemanticsFlagy  or  Check  VCsFlagy,  then  set 

CheckVCsFlagx- 


Step  4b,  which  Is  applied  when  X is  semantically  consistent,  requires  further 
explanation.  It  decides  whether  or  not  a semantic  inconsistency  can  arise  In  the  VCs  of  X. 
1 his  can  happen,  for  example,  when  X calls  a unit  that  is  semantically  Inconsistent,  as  was  Just 
illustrated  when  Exchange  called  IsExchangcd.  Under  certain  conditions,  other  inconsistencies 
In  the  data-base  structure  can  also  arise  In  the  VCs  for  X.  For  now,  it  suffices  to  say  that  If 
any  program  called  by  X has  CheckSemanticsFlag  or  ChcckVCsFlag  set,  then  CheckVCsFlagx 
is  set.  It  is  explained  later  how  this  fits  into  the  scheme  for  preventing  things  like  generating 
Inconsistent  VCs  for  Exchange. 

Notice  that  local  cross  references,  such  as  CalIsFromInternals,  are  not  updated. 
Perhaps  an  additional  step  Is  needed!  Actually,  calls  to  undefined  units  are  filled  in  prior  to 
their  definition  by  the  first  two  steps  above  or  by  the  algorithm  In  Section  4.4.  When 
Exchange-sort  called  Exchange  in  the  previous  example,  this  fact  was  noted  immediately  in  the 
data  base  before  Exchange  was  defined. 


4.4  Revising  Programs  and  Their  Specifications 

A difficult  problem  In  Incremental  environments  is  how  to  effectively  determine  the 
effects  of  changes  to  existing  data.  Section  4-1  outlined  a general  approach  to  this  problem 
which  is  formalized  here.  Sections  4.5  and  4.6  present  some  ideas  (not  previewed  In  Section  4.1) 
for  performing  a finer  analysis  of  specifications  and  VCs,  respectively.  Some  auxiliary 
functions  are  introduced  before  the  main  algorithm  for  handling  revisions  is  stated. 
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1 function  Loc^lion_,o(_max(A:inl_array;  i,J:tnt):int  « 

2 bcc.in 

3 entry  1 in  [1..N]  and  J in  [1.  N]  and  I le  J; 

'I  exit  Location.  o(_ir)ax(A,l,J)  in  [I..J] 

5 and  A(Localion_of_niax(A,l,J)]  = Value_of_max(A,(,J); 

6 viir  K;int  :=  1; 

7 keep  I to  J and  I in  [l.N]  and  J in  [1..N]  and  K in  [l-NJ; 

R rc-'.ult  I; 

9 loop 

to  a-sert  A[result]  * Valuc_of_max(A,l,K) 

I I and  result  in  [1..K]  and  K in  [I..J]; 

I 2 it  K p,o  J then  leave  end; 

13  K:=K«1; 

1 4 if  A[rfcsult]  < A(k]  then  result  :=  k end; 

1 5 end; 

16  end; 

Figure  4-10,  Definition  of  Local ion_ofjnax 


Four  boolean-valued  functions  are  used  for  determining  what  parts  of  a unit  X are 
changed  In  X’.  Examples  of  different  parts  considered  are  taken  from  the  definition  of 
I .ocation.of  jnax  in  Fig.  4-10.  1 he  first  needed  function  1$ 

ChangeInHeader(X,X’) 

which  Indicates  whether  the  header  of  X has  been  revised  In  X’.  The  header  for 
l.ixation.of jnax  is  on  line  I.  The  function 

ChangelnExternalSpccs(X,X’) 

detects  changes  in  external  specifications  (lines  3-5)  1 hese  are  the  only  two  functions  needed  to 
detect  changes  that  have  global  effects.  Next,  changes  to  external  or  internal  specifications  are 
detected  by 


ChangelnSpecs(X,X') 


Page  85 

Changes  to  these  specifications  can  have  local  effects  on  the  assocated  unit.  Changes  to  lines  3, 
5,  7,  10,  and  II  can  affect  the  verification  of  Location_ofjnax.  The  function 

ChangeInBody(X,X') 

detects  changes  to  lines  2-16,  excluding  specifications. 

AH  four  of  these  functions  detect  semantic  as  well  as  syntactic  differences.  For 
example,  ChangelnExternalSpecs  checks  for  exit  specifications  that  are  syntactically  Identical, 
but  have  variables  of  different  types.  Free  variables  may  be  bound  to  one  type  in  the 
parameter  list  of  X and  to  another  in  X’. 

1 he  two  functions  given  below  are  used  by  several  algorithms  for  verification 
purposes.  I hey  both  reflect  the  policy  of  fully  expanding  VCs,  i.e.,  of  assuming  that  all 
potentially  usable  specifications  are  in  fact  used  in  proofs.  Section  4-10  changes  these  functions 
to  account  for  those  specifications  actually  used. 

The  function  MarkToCheckVCs  traces  the  effects  of  an  inconsistent  external 
specification  through  the  data-base  structure,  marking  those  units  whose  verification  is  affected. 
For  a unit  X, 

MarkToCh«ckVC5(X)> 

for  each  Y in  CallsFromExiernatSpecsj^  or  CallsFromlnlornalsj^ 

(set  CheckVCsFla|>y; 
if  Y in  CallsFromExlernalSpecs)(  then 
MarkToCheckVCs(Y)  ) 

Suppose  that  X has  a type  conflict  in  its  exit  specification.  1 hen,  MarkToCheckVCs  sets 
C.hock  VCsFlag  for  those  units  that  have  the  exit  specification  of  X in  at  least  one  of  their  VCs. 
1 he.se  affected  units  are  Identified  by  tracing  upward  through  the  graph  of  calling 
relationships,  beginning  with  X.  Traversal  of  a path  terminates  when  the  inconsistent 
specification  can  be  exported  no  further  — i.e.,  when  it  cannot  be  exported  to  another  unit  via 
externally- visible  specifications.  For  units  not  having  VCs,  the  algorithms  work  independent  of 
whether  or  not  MarkToCheckVCs  sets  their  CheckVCsFlag. 

The  function  IsPathConsistent  determines  whether  there  is  a semantic  inconsistency 
in  the  data  base  that  would  affect  at  least  one  of  the  VCs  for  unit  X. 
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l«PathConsistent(X  )> 

H CheckSemanticsFlag^  then  false 
else  if  ChecKVCsFlag^  then 

(if  IsPathConsistent(Y)  is  true  for  every  Y in  ExternalSpecCallaTotX) 
then  true 
else  false  ) 
else  true  ; 

IsPathConsistent  Is.  in  a sense,  the  inverse  of  MarkToChcckVCs.  MarkToCheckVCs 
traversed  upward  paths  to  find  all  units  to  which  potentially  inconsistent  specifications  could  be 
exported,  whereas  IsPathConsistent  traverses  downward  paths  to  sec  if  there  is  a potentially 
inconsistent  specification  that  would  be  imported.  Again,  the  key  observation  is  that 
inconsistencies  propagate  only  through  externally-visiblc  specifications. 

A five-step  algorithm  for  handling  changes  to  a unit  follows.  The  first  four  steps 
perform  the  necessary  global  analysis,  marking,  and  updating,  while  the  fifth  step  handles  local 
tasks.  The  entire  algorillmi  is  formally  stated,  tlicii  each  main  step  is  explained. 

Algorithm  R.  If  a program  unit  X Is  replaced  by  the  unit  X',  then  the  following  steps  are 
performed  in  order. 

1.  Check  the  header.  If  ChangeInHeader(X,X'),  set  CheckSemantlcsFlagy 
for  each  Y In  CallsFromlnternalsy^*  or  CallsFromExternalSpecsy,  execute 
MarkToCheckVCs(Y)  for  each  Y in  CallsFromExternalSpecsy^*,  and  go  to 
step  3. 

2.  Check  external  specifications.  If  ChangcInF,xternal£pccs(X,X’), 
then  (if  .^rmantirallyConsfstent(X).  ScmanticallyConsistent(X'),  and 
IsPathConsistcnt(Y)  Is  true  for  each  Y in  ExtcrnalSpecCallsTo(X)  and 
I xternalSpccCiallsI  o(X  ) then  (call  MarkToChcckVCs(X’)  if  Algorithm  C 
is  false)  else  call  MarkToChcck VCs(X’)). 

3.  Delete  cross  references.  For  each  Y in  lnternalCallsTo(X)  and  not 
In  InternalCallsTo(X'),  delete  X from  CalIsFromIntcrnalsY.  Perform  this 
step  again  replacing  InternalCallsl'o  by  ExternalSpecCallsTo  and 
CalIsFromInternals  by  CalIsFromExtcrnalSpecs. 

4.  Add  cross  references.  For  each  Y in  InternalCallsTo(X’)  and  not  in 
InternalCallsl  o(X),  add  X’  to  CallsFromlnternalsY.  Perform  this  step  again 
replacing  InternalCallsIb  by  ExternalSpecCallsTo  and  CalIsFromInternals 
by  CalIsFromExtcrnalSpecs. 

5.  Local  updating.  Perform  the  following  steps  in  order  until  one  succeeds. 
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5a.  Check  semantics.  If  not  ScmantlcallyConslstent(X’),  then  set 
ClheckScmanticsFlag)^'. 

5b.  Prerent  import  of  inconsistent  specifications.  If 
there  Is  a Y In  ExternalSpecCal!sTo{X')  or  lnternalCa11sTo(X’)  such 
that  IsPathConsistent(Y)  Is  false,  then  set  Check VCsFlag^’- 

5c.  Any  previous  proofs?  If  Status^  Is  "no  proofs  established",  then 
set  Statusy^’  to  "to  be  VC  generated". 

5d.  Keep  intact  all  proofs.  If  not  ChangelnBody  (X,X’), 
ScmantlcallyConslstent(X),  Check  VCsFlag^  Is  not  set, 
ChangeInSpecs(X,X’),  and  Algorithm  L Is  true,  then  set  Statusy  to 
Status^. 

5e.  Must  check  proofs  individually.  Set  CheckVCsFlagj^*. 


Algorithms  G and  L determine  the  global  and  local  Impact  of  changes  to  specifications  <see 
Section  -1.5).  Omitted,  for  clarity,  from  this  and  other  algorithms  are  explicit  statements  of 
"inherited"  attribute:value  pairs.  I'he  reader  should  assume  that  such  inheritance  always  occurs 
unless  stated  otherwise.  In  step  I,  for  example,  CallsFromlnternalsj^'  Is  the  same  as 
CalIsFromInternalsy. 

Figure  4-M  presents  another  data  base  structure  that  will  be  used  for  expository 
purposes  As  with  the  sorting  example,  names  represent  program  units  (basis  properties  will  be 
added  later)  and  arrows  indicate  calls. 

Step  I determines  the  global  Impact  of  changing  the  header  of  a program.  Suppose 
that  X takes  two  arguments  and  is  replaced  by  X'  which  takes  only  one.  Step  I ensures  that  all 
direct  callers  of  X’  (viz.,  A and  B)  are  checked  for  semantic  consistency.  After  A and  B are 
marked,  MarkToCheck VCs  marks  all  units  that  have  at  least  one  VC  containing  a type 
ml.smatch.  If,  for  example,  the  external  specifications  of  A call  X’  and  those  of  D call  A,  all 
markings  performed  by  this  step  are  Illustrated  In  Fig.  4-12.  Notice  that  H,  F,  and  C are  not 
affected  In  any  way  by  the  change  to  X.  FI  Is  not  affected  because  the  external  specifications  of 
C do  not  call  A,  meaning  that  any  Inconsistent  specification  in  C cannot  be  exported  to  H. 
Similarly,  F and  G are  not  affected  by  the  change,  because  the  external  specifications  of  B do 
not  call  X’. 


1 


1 

1 
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Step  2 determines  the  global  effects  of  changing  the  external  specifications  of  X. 
Algorithm  (,  Is  called  to  determine  if  the  needed  logical  relationship  holds  between  the  external 
specifications  of  X and  X’.  Algorithm  G docs  not  apply  when  these  specifications  either 
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contain  type  conflicts  or  can  have  inconsistencies  Imported  into  the  proofs.  This  latter 
condition  again  reflects  the  conservative  view  of  fully  expanding  specifications.  When 
Algorithm  G falls  or  cannot  be  called,  MarkToCheckVCs  marks  the  same  units  as  does  step  I. 
The  only  difference  being  that  direct  callers  are  marked  as  being  verification  (instead  of  design) 
inconsistent. 

Steps  3 and  < update  global  cross  references.  The  former  removes  cross  references 
established  for  X that  no  longer  hold  for  X'.  Conversely,  step  4 establishes  cross  references  for 
X’  not  made  for  X. 

Locally,  step  5 ensures  that  still-valid  verification  work  on  X is  kept  intact.  This  is 
done  immediately  when  possible;  otherwise,  the  appropriate  flags  are  set  when  analysis  must  be 
po.stponed.  Steps  5b-5e,  applied  when  X’  Is  semantically  consistent,  require  further  explanation. 
Suppose  that  D is  replaced  In  Fig.  4-12  by  D’.  Step  5b  sets  Check VCsFlagu*  because  of  the 
type  mismatch  in  the  exit  specification  of  A.  Now  suppose  that  the  specifications  of  H (in  Fig. 
4 12)  are  revised  in  H’.  After  step  5c  ensures  that  H is  at  least  partially  verified,  step  5d 
applies  Algorithm  L under  the  appropriate  conditions.  When  it  succeeds,  all  proofs  about  FI 
hold  for  FF’.  If  all  proofs  cannot  be  kept  Intact  Immediately,  those  that  can  are  identified  later 
(cf.  Section  4.6).  Step  5e,  along  with  steps  5a  and  5b,  postpone  the  analysis. 


4.5  Changes  to  Specifications  May  Not  Have  Effects 

Because  specifications  are  frequently  revised,  it  is  useful  to  recognize  when  changes  to 
specifications  of  a unit  do  not  affect  its  verification  or  the  verification  of  Its  callers.  Unlike  for 
changes  to  programs,  this  is  viable  to  do  on  a case-by-case  basis.  A change  to  a specification 
has  no  effects  If  certain  logical  relationships  between  the  revised  specification  and  Its  previous 
version  hold.  The  algorithms  for  checking  this  are  driven  by  tables  which  contain  a 
description  of  what  these  relationships  are  for  each  kind  of  specification.  The  discussion  below 
describes  how  to  set  up  the  tables,  then  presents  the  algorithms  which  use  them. 

Setting  Up  The  Tables 

Table  entries  for  specifications  consist  of  three  parts: 

• The  textual  name  used  to  identify  the  specification. 

• A desig^nation  of  a formula  relating  a revised  specification  to  its  previous 
version.  These  formulas,  of  course,  vary  according  to  the  program  proof 
techniques  employed.  If  omitted,  a default  of  false  is  assigned. 
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• An  Indication  as  to  whether  failure  to  prove  the  designated  formula  has  local 
or  global  effects.  Changes  to  some  specifications  can  have  both  kinds  of 
effects,  In  which  case  two  table  entries  are  required.  I'raditional  entry  and 
exit  specifications  are  In  this  category. 

or  course,  it  does  not  matter  whether  local  or  global  descriptions  are  actually  stored  in  separate 
tables  or  combined  into  one. 

As  a specific  example  of  how  to  describe  specifications,  we  will  d>^velop  a set  of  kKal 
and  global  table  entries  for  entry  and  exit  specifications,  beginning  with  the  local  entries. 
Table  declarations  are  of  the  form 

Declarafaffect 

(specification-name  formula) 

(specification-name  formula)) 

Using  this  template,  a description  for  determining  local  effects  Is 

Declare  (local 

(entry  entry'^entry) 

(exit  exit^exit')) 

T his  states  that  changes  to  entry  specifications  do  not  affect  the  verification  of  the  associated 
program  if  the  changed  entry  specification  implies  the  unchanged  one.  The  converse  relation 
must  hold  for  exit  specifications.  Both  descriptions  follow  from  Hoare's  rule  of  consequence.  ^ 

Globally,  entry  and  exit  specifications  of  a program  can  arise  in  the  VCs  of  its  callers 
In  several  ways.  Suppose  that  the  proof  strategy  handles  program  calls  by  proving  that  entry 
specifications  hold  at  all  calling  sites  and  by  adding  formulas  of  the  form  entry^exlt  (composed 
of  specifications  from  callees)  to  VCs  of  callers.  Then,  the  description  for  global  effects  is 


^ The  rule  of  consequence  is; 

Q{S)R. 


P{S}T 

SID  employs  this  scheme,  among  others.  It  instantiates  and  proves  entry 
specifications  at  all  calling  sites  and  adds  uninstantiated  formulas  of  the  form  entry^exlt  to  VCs 
during  proofs. 
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D«cl«r«  Cslobal 

(entry  entrysentry') 

(exit  it  entrysentry*  then  exit'^exit 

elte  (eniry'sexil’)  a (entry^exit))) 

This  says  that  changing  an  entry  specification  has  no  global  effects  when  the  unchanged  entry 
empties  the  changed  entry.  The  exit  relationship  is  described  as  an  if-thcn-else  statement  to 
take  advantage  of  knowledge  about  what  has  changed.  If  the  entry  has  not  changed  since  the 
last  time  the  exit  changed,  the  test  is  automatically  true  and  a proof  of  the  simpler  formula  on 
the  then  branch  is  attempted. 

SID  uses  this  kind  of  knowledge,  as  is  evident  in  the  following  interchange. 

<-  What  dees  chanEine  its  exit  assertion  affec!? 

’’its"  refers  to  Locations f ^ax. 


Tha  varification  of  other  programs  is  not  affeciad  if  the  formula 
Changed  exit  specification 
— > 

Cl:  L(X:ATI0N_0F_MAX(A,  I,  J)  in  [I  .J] 

C2:  A[LOCATION_OF_MAX(A,  I,  J)]  = VALUE_OF_MAX(A,  I,  J) 
is  true.  If  not,  the  change  invalidates  the  verification  of  EXCHANGE_SORT. 


The  formulas  In  the  answer  come  from  the  above  If-then-else  rule  for  exit  specifications.  Since 
the  entry  specification  of  Location_of_max  has  not  changed,  the  answer  refers  only  to  its  exit 
specifications.  When  SID  actually  attempts  to  prove  such  formulas,  all  free  variables  are 
bound  and  typed.  The  type  information  comes  from  the  symbol  tables. 


Global  descriptions  follow  from  the  following  sound,  first -order  Inference  rule; 
V...(H|  3H2).  V...(H2aH3  3C) 


V...(Hi  aH3  3C) 

H|.  H2,  H3,  and  C are  first-order  formulas  whose  free  variables  are  universally  quantified  as 
indicated  above.  This  rule  is  called  the  rule  of  revision.  Figure  4-IS  illustrates  its  use  in 
deriving  the  global  entry  and  exit  descriptions  given  above.  Only  the  then  branch  of  the  if- 


Algorithms  for  Msnipulating  the  Tables 

It  is  now  trivial  to  write  the  algorithms  for  analyzing  changes  to  specifications.  Two 
are  called  from  Algorithm  R.  The  first  is  Algorithm  C,  which  determines  If  changes  to 
external  specifications  have  global  effects.  Algorithm  L determines  If  changes  to  Internal  or 
external  specifications  have  local  effects  on  the  associated  unit. 

Algorithm  C.  For  each  global  description  In  the  table,  If  the  specification  textually  identified 
by  specification-name  is  different  in  units  X and  X’,  then  return  the  truth  value  of  the 
corresponding  formula. 


Before  executing  this  algorithm,  SID  first  sees  if  there  is  at  least  one  unit  traversed  by 


Papp  94 


Mark'roChcckVCs(X’)  that  1$  partially  or  completely  verified.  Effort  expended  In  trying  to 
prove  the  designated  formulas  Is  wasted  unless  succeeding  proofs  will  keep  intact  previously- 
done  verification  work. 

Algorithm  L.  For  each  local  description  In  the  table,  if  the  specification  textually  identified  by 
specification-name  Is  different  in  units  X and  X',  then  return  the  truth  value  of  the 
corresponding  formula. 


4.6  Deducing  Which  VCs  Are  Unaffected  by  Changes 

We  have  already  seen  several  ways  to  keep  intact  work  unaffected  by  changes. 
Section  4 4 described  ways  to  Identify  those  units  whose  design  or  verification  are  affected  by 
changes,  using  the  techniques  In  Section  4.5  for  analyzing  changes  to  specifications.  Often, 
however,  changes  affect  only  a few  VCs  of  a unit.  VCs  can  be  analyzed  individually  to 
determine  whether  or  not  they  are  affected  by  changes.  Algorithm  V,  which  is  described  below, 
Is  applied  under  certain  conditions  for  this  purpose.  These  conditions  are  enforced  by  the 
algorithm  In  Section  4.7  for  resolving  Inconsistencies. 

The  algorithm  works  by  "comparing"  new  and  old  VCs  to  determine  If  their  proofs 
coincide.  Whatever  the  scheme  for  doing  this  comparison,  both  syntactic  and  semantic  concerns 
must  be  satisfied.  Algorithm  V uses  a simple  "equivalence"  test  - the  new  and  old  VC  must  be 
the  same  syntactically  within  a uniform  change  of  variables  and  semantically  symbol  for 
symbol.  Uniform  variable  renaming  Is. added  as  a special  case  so  that  the  common  source 
program  change  of  uniformly  renaming  an  identifier  will  not  necessitate  any  reverlfying. 

Algorithm  V.  Let  VC  designate  a verification  condition  of  X and  VC'  a verification  condition 
of  X’.  For  every  VC’, 

I.  If  there  is  an  at  least  partially  proved  verification  condition  VC  such  that  it 
and  VC  satisfy  the  equivalence  test  described  above  then  set  the  status  of 
VC  to  that  of  VC. 

2 Otherwise,  the  status  of  VC  becomes  "to  be  proved". 

When  checking  the  semantic  criteria  for  equivalence,  the  type  of  free  variables  in  VC  are  in 
SymTabj^*  and  those  In  VC  are  in  SymTaby.  In  SID,  this  algorithm  is  not  applied  to  VCs 
that  simplify  to  true  during  generation. 

Aware  that  type  errors  In  X may  only  affect  some  of  Its  VCs  and  their  proofs, 
Algorithm  V keeps  Intact  those  parts  that  hold  for  X’.  The  equivalence  t»st  always  fails  for 
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those  VCs  of  X that  contain  type  errors,  because  VCs  for  X’  are  type  correct  (cf.  Section  4.7). 
For  example,  a verification  condition  with  the  wrong  number  of  arguments  to  a function  causes 
the  syntactic  comparison  to  fail.  Things  like  a wrong  argument  type  in  a function  call  or  a 
wrong  variable  type  In  an  expression  cause  the  semantic  comparison  to  fall. 

There  are  many  variations  on  Algorithm  V and  several  practical  tradeoffs  among 
them.  One  is  showing  that  previously  proved  VCs  are  semantically  consistent  and  that  they 
imply  new  ones,  establishing  the  latter  by  modus  ponens.  Another  is  attempting  recovery  at 
the  subgoal  level,  rather  than  the  VC  level  - implying  several  complexities  mostly  related  to 
theorem  proving.  These  and  some  other  variations  require  more  processing  (in  varying 
degrees)  than  Algorithm  V and  may  also  require  human  assistance.  Algorithm  V is 
straightforward  and  requires  no  human  intervention. 


4.7  Resolving  Inconsistencies 

This  section  describes  the  policy  for  determining  which  manipulations  can  be 
performed  on  data-base  structures.  The  policy  does  not  consider  operations  that  do  not  change 
the  state  of  the  data  base  (eg.,  display  operations)  because  they  can  always  be  executed.  It  also 
omits  from  consideration  the  always-allowed  operation  of  translating  data.  Placing  no 
restrictions  on  when  translation  can  occur  enables  the  user  to  add  to  or  revise  the  data  base  at 
his  convenience. 

The  policy  adopted  must  embody  some  definition  of  what  It  means  for  an  operation 
to  be  legitimate.  Here,  an  operation  is  legitimate  if  It  makes  sense  and  if  it  would  cause  a 
consistent  state  change  on  the  data  base.  A simple  status  mechanism  suffices  to  limit  the 
applicable  operations  when  everything  in  the  data  base  is  consistent.  For  example,  if  the  status 
of  a unit  is  "to  be  VC  generated",  a "prove  VCs"  command  is  nonsensical.  Complexities  arise 
here  because  the  data  base  frequently  contains  inconsistent  data,  requiring  that  the  local  state 
of  development  and  the  global  data-base  configuration  be  taken  into  account. 

The  following  algorithm  views  the  semantic  checking  of  a unit  as  an  operation  that 
cannot  be  requested  - it  Is  performed  automatically  by  the  algorithm  when  needed. 
Reformulating  the  steps  without  this  assumption  Is  trivial.  Steps  I - 3 ensure  that  only 
consistent  state-changing  operations  are  performed;  step  4 ensures  that  the  operation  makes 
sense  in  situations  where  inconsistencies  are  not  possible. 

Algorithm  RI.  For  a unit  X,  perform  the  following  steps  In  order; 

I.  If  CheckSemanticsFlagy  or  Check  VCsFlagj^  Is  set,  then  If  IsPathConsistent 
(Y)  is  false  for  some  Y In  InternalCallsTo  (X)  or  ExternalSpecCallsTo  (X), 
the  operation  is  not  allowed. 
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2.  If  CheckSemanlicsFlagy  is  set,  then 

2a.  If  SemanticallyConsistent(X)  and  the  operation  Is  "generate  VCs",  then 
generate  VCs  for  X,  execute  Algorithm  V,  reset  CheckSemantlcsFlag^ 
and  Check VCsFlag^i  and  update  Status)^. 

2b.  Otherwise,  the  operation  Is  not  allowed. 


3.  If  Check  VCsFlagy^  is  set,  then 

3a.  If  the  operation  is  "generate  VCs",  then  generate  VCs  for  X,  execute 
Algorithm  V,  reset  CheckVCsFlagy^,  and  update  Status^. 

3b.  Otherwise,  the  operation  is  not  allowed. 

4.  If  Statusy^  Indicates  that  the  operation  is  legitimate,  then  perform  It  and 
update  Status^,  otherwise  the  operation  is  not  allowed. 

Step  I prevents  inconsistencies  in  the  data  base  from  causing  an  Inconsistent  state 
change.  In  Fig.  4-12,  this  step  ensures  that  the  VCs  for  1,  C,  D,  and  E are  not  generated  until 
the  semantic  inconsistency  is  removed  from  the  external  specification  of  A. 

Step  2 resets  CheckScmanticsFlag  only  when  a unit  is  semantically  consistent  and  the 
operation  is  "generate  VCs".  If  VCs  are  generated.  Algorithm  V attempts  to  keep  Intact 
previous  proofs  that  remain  valid.  Then  the  new  state  of  development  Is  reflected  In  the  data 
base  by  resetting  the  flags  and  updating  the  status  for  the  associated  unit.  Further,  It  prevents 
the  VCs  for  A and  B from  being  generated  until  A and  B are  semantically  Inconsistent  with 
X’. 

Updating  the  status  of  a unit  is  a straightforward  process  performed  only  when  It  has 
no  Inconsistencies.  The  exact  procedure,  however,  depends  upon  the  characteristics  of  the 
underlying  design  and  verification  system.  For  example,  if  the  status  of  a unit  is  "to  be  VC 
generated",  after  VC  generation  the  status  may  be  one  of  "to  be  proved",  "partially  proved", 
"proved",  etc.  The  actual  setting  depends  on  whether  the  VC  generator  combines  proving  with 
the  VC-generation  process. 

Step  3 handles  units  who.se  only  set  flag  Is  CheckVCsFlag.  It  does  not  apply,  for 
example,  to  units  A and  B of  Fig.  4-12.  CheckVCsFlag  Is  reset  after  generating  VCs  for  the 
current  unit  and  applying  Algorithm  V.  The  status  is  updated  as  before. 
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Step  4 Is  applicable  only  when  the  current  unit  Is  design  and  verification  consistent. 
Status^  delimits  the  set  of  legitimate  operations  and  is  updated  when  s'l  operation  Is 
performed.  For  example,  if  Statusy  is  "to  be  VC  generated",  then  the  "prove  VCs"  operation  is 
not  legitimate. 

Let  us  now  see  how  Algorithm  Rl  applies  to  Fig.  4-12.  Units  H,  F,  and  C can  always 
be  manipulated  by  step  4 because  they  do  not  contain  and  cannot  be  affected  by  inconsistencies 
in  the  structure;  X’  can  be  operated  on  by  step  2.  Operations  on  all  other  units  are  ruled  out 
by  step  I.  since  a state  change  cannot  be  guaranteed  to  be  consistent.  Inconsistencies  In  X*  and 
then  A must  be  removed  by  step  2a  before  C,  D,  E,  and  I can  have  VCs  generated  by  step  Sa. 


4.8  Basis  Properties:  Lemmas,  Rewrite  Rules,  and  Definitions 

We  are  now  ready  to  add  basis  properties  to  the  data-base  structure.  These 
properties  typically  call  functions  already  in  the  data  base.  Figure  4-14  illustrates  how  such 
calls  are  reflected  in  the  data  base  by  adding  basis  properties  Bj,  B2,  and  B3  to  Fig.  4-12.  X,  1, 
and  F are  functions  called  by  Bj,  B2,  and  Bj,  respectively.  Using  basis  properties  in  proofs  ties 
them  into  the  data-base  structure  even  more  intimately. 

In  this  extended  data  base,  changes  to  basis  properties  can  affect  verifications,  and 
changes  to  programs  can  affect  basis  properties  and  the  proofs  In  which  they  were  used.  Both 
situations  are  studied  in  this  section.  Included  in  the  discussion  are  specific  rules  for  showing 
that  changes  to  basis  properties  have  no  effects.  These  rules,  like  the  ones  for  specifications, 
describe  needed  logical  relationships  between  a revised  basis  property  and  its  previous  version. 

The  different  kinds  of  basis  properties  discussed  (which  are  the  kinds  handled  in 
Sill)  are  lemmas,  rewrite  rules,  conditional  rewrite  rules,  and  definitions.  All  are  assumed  to  be 
syntactically  and  semantically  checkable.  As  a result,  things  like  function  calls  in  lemmas  must 
be  cfiecked  for  the  right  number  and  type  of  arguments.  Of  course,  the  needed  information 
may  be  either  user-defined  (such  as  function  definitions  In  the  data  base)  or  built  Into  the 
semantic  checker. 


C:hanges  to  Basis  Properties  May  Not  Have  Effects 

For  a new  or  changed  basis  property  B,  the  following  steps  perform  the  necessary 
local  analysis; 

I.  If  not  SemanticallyConsistent(B),  set  CheckSemanticsFlagg. 
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2.  Otherwise,  if  the  data  base  contains  a function  X called  by  B such  that 
IsPathConslstent(X)  Is  false,  then  set  NotUsableFlagg. 

Step  I ensures  that  a semantically  inconsistent  basis  property  is  not  used  In  proofs;  step  2 keeps 
semantically  Inconsistent  specifications  from  being  added  to  proofs  through  basis  properties. 
The  setting  of  NotUsablcFlag^  or  ChcckSemanticsFlag^  prohibits  use  of  B In  proofs  until 
both  are  reset.  NotUsableFlagg  is  reset  when  inconsistent  specifications  can  no  longer  be 
introduced  In  proofs  via  B.  This  is  determined  analogously  to  step  I of  Algorithm  RI. 
CheckSemanticsFlagg  Is  reset  when  all  semantic  errors  are  removed  from  B. 

Changes  to  basis  properties  also  can  have  an  impact  on  the  rest  of  the  data  base. 
The  procedure  for  determining  this  global  impact  is  highlighted  below. 

1.  If  not  (ScmanticallyConslstent(B)  and  ScmanticallyConsistent(B’)),  or  if 
IsPathConsistent(Y)  is  false  for  at  least  one  function  Y called  by  B or  B*,  or 
if  the  comparison  described  below  between  B and  B’  is  not  successful,  then 
add  B to  Check BasisFlag^  for  each  X In  Useding. 

2.  Otherwise,  no  proofs  are  affected. 

I'he  conservative  set  of  conditions  given  in  step  I are  the  same  as  those  required  to  compare 
two  specifications.  Comparison  rules  for  the  four  kinds  of  basis  properties  are  given  below. 

Lew  w MS.  For  a lemma  L and  its  replacement  L',  the  rule  of  revision  says  that  if  the  formula 

l.’3  L 

Is  true,  then  proofs  depending  on  L remain  valid  for  L'. 

What  happens  if  a basis  property  is  deleted,  rather  than  revised?  If  the  deleted 
property  is  shown  to  be  logically  valid,  proofs  depending  on  it  remain  valid.  That  Is,  they  can 
be  done  without  it. 

Rewrite  rules.  A rewrite  rule  is  represented  as 

A - > B 

and  is  applied  by  changing  ail  subformulas  of  the  form  A into  the  form  B,  but  not  vice  versa. 
T he  underlying  semantics  of  these  rules  in  SID  is  equality.  That  Is,  If  a theorem  is  proved 
using  A ->  B,  it  can  also  be  proved  using  A - B.  This  observation  together  with  the  rule  of 
revision  indicates  that  establishing  the  formula 


(A’  - B’)  3 (A  - B) 
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shows  that  proofs  using  the  rewrite  rule  A ->  B can  also  be  done  using  A’  - > B’. 


CondittonMl  rewrite  rules.  I'hcse  are  slight  generalizations  of  rewrite  rules  in  which 
a rewrite  is  performed  only  if  a given  condition  is  true.  Proofs  using  a rewrite  rule  A -->  B 
when  condition  C is  true  remain  valid  for  its  replacement  whenever  the  formula 

(C  3 A’  « B’)  3 (C  3 A - B) 

Is  proved. 

Definitions.  A definition  is  a statement  that  establishes  the  meaning  of  an  expression. 
An  example  of  how  they  arise  In  Gypsy  is  the  definition  of  IsExchanged  on  lines  68-70  of  Fig. 
4-1  Generally,  the  definition  for  an  n-place  function  F can  be  stated  as 

F = E 

F is  the  definiendum  and  the  definlen  E Is  an  expression.  Definitions  behave  like  rewrite  rules 
(replacing  F by  E)  in  proofs  (as  illustrated  by  the  expansion  of  the  definition  of  IsExchanged  In 
Section  3-3).  Showing  that 

E’  - E 

holds  when  the  definien  changes  indicates  that  proofs  depending  on  E remain  valid  for  E’. 
Changes  to  F are  handled  by  Algorithms  R and  V. 

Changes  to  Programs  May  Affect  Basis  Properties  and  Proofs 

Adding  basis  properties  requires  minor  extensions  to  Algorithms  R and  V. 
Algorithm  R must  account  for  the  fact  that  a change  to  the  header  of  a function  may  cause  a 
type  conflict  In  all  calling  basis  properties,  in  turn  rendering  prewfs  in  which  they  were  used 
inconsistent.  Step  I of  Algorithm  R,  using  CalIsFromBasisProps  to  Identify  calling  properties, 
is  easily  extended  for  this  purpose. 

Another  extension  is  illustrated  with  the  aid  of  Fig.  4-14.  With  the  addition  of  basis 
properties,  MarkToCheckVCs  must  alter  its  behavior.  Whenever  It  encounters  a program  unit 
that  can  export  an  inconsistency,  it  must  set  NotUsableFlag  for  each  calling  basis  property. 
Setting  NotUsableFlag  in  turn  causes  CheckBasisFlag  to  be  set  for  each  unit  that  used  the 
property  In  its  proof.  Figure  4-15  illustrates  the  complete  set  of  markings  for  Fig.  4-13,  if  B| 
was  used  In  the  proof  of  C and  if  1 can  export  an  inconsistency  to  Its  callers. 


Algorithm  V must  exclude  VCs  whose  proofs  use  a subsequently  Invalidated  basis 


Page  101 


Figure  4-15.  Changes  to  the  header  of  X can  affect 
basis  properties  and  proofs 
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property  from  consideration.  A VC  is  excluded  if  the  intersection  of  the  basis  property  names 
in  Check  BasisFlag  with  those  in  the  VC’s  Used  attribute  is  non-empty. 


4.9  Types  and  Data  Abstractions 

So  far,  the  methodology  applies  to  functions,  procedures,  concurrent  processes  of 
Gypsy,  and  basis  properties.  1 his  section  extends  it  to  handle  language  mechanisms  for 
defining  data  abstractions,  examples  of  which  can  be  found  in  Simula  [Dahl  and  Hoare  72], 
Clu  [Liskov  75],  and  more  recently  in  Alphard  [Wulf,  et  al.  76]  and  Gypsy  [Ambler,  et  al.  77]. 
Since  these  mechanisms  subsume  ordinary  type  definitions,  the  methods  described  for  data 
abstractions  also  work  for  ordinary  types. 

The  highlights  of  this  section  are  as  follows: 

• Data-base  representation.  Data  abstractions  are  viewed  as 
consisting  of  a type  definition  for  the  abstract  object  and  programs  for 
manipulating  it.  These  units,  accompanied  by  their  specifications,  are  stored 
separately  in  the  data  base  and  tied  together  by  pointers. 

• Two  key  relations,  integrating  type  definitions  into  the  data-base 
structure  involves  two  relations,  instead  of  the  single  calling  relation  used 
before.  These  relations  distinguish  declaration  sites  from  reference  sites. 

• Changes  to  types.  The  effects  of  changes  to  type  definitions  (unlike 
changes  to  programs)  do  not,  with  one  exception,  propagate  through  the 
data-base  structure.  The  two-relation  description  allows  affected  units  to  be 
identified  directly. 

• Other  changes.  Everything  else  (including  the  exception  noted  above) 
follows  from  already-developed  principles. 

1 he  following  outlines  the  main  details  surrounding  each  of  these  points,  beginning  with  a 
discussion  of  extensions  to  the  data  base. 


Representing  Data  Abstractions  in  the  Data  Base 

A data  abstraction  Is  viewed  as  consisting  of  a restricted  type  definition  for  the 
abstract  object  and  operations  that  manipulate  the  internal  structure  of  the  object.  The  word 
"restricted”  is  used  to  emphasize  that  users  of  the  abstraction  do  not  have  access  to  its  internal 
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structure  - only  the  associated  operations  do.  The  representation  given  below  suffices  for 
describing  data  abstractions  written  in  Gypsy.  Of  course,  additions  or  deletions  may  be  needed 
for  other  languages. 

Restricted  type  definitions  may  have  four  parts; 

1.  A header  that  Includes  the  name  of  the  abstract  object  and  an  optional 
parameter  list. 

2.  External  specifications  about  parameters.  These  specifications  must  hold 
whenever  an  Instance  of  the  type  is  declared. 

3.  External  specifications  that  can  be  assumed  In  proofs  of  all  users  of  the 
abstraction  (eg.,  abstract  axioms). 

i A body  which  defines  the  implementation  of  the  abstract  object. 

Declarations  that  create  Instances  of  an  abstract  object  refer  to  the  entities  In  part  I and  must 
also  satisfy  any  restrictions  on  parameters  in  part  2.  1 he  specifications  in  part  3,  In  contrast  to 
those  in  part  2,  hold  everywhere  the  abstraction  is  referenced,  except  possibly  for  states  within 
units  that  access  the  Internal  structure  of  the  restricted  type.  The  body  of  a restricted  type  unit 
Is  visible  only  to  those  units  given  access. 

Program  units  that  access  restricted  types  are  Just  like  other  program  units,  except  for 
.some  additional  specifications.  I'hese  specifications  are  used  in  showing  the  needed  abstract- 
concrete  relationship,  I.e.,  that  the  implementation  "models"  the  abstraction. 

Four  new  attribute:value  pairs  are  added  to  the  data  base.  The  first  three  are 
associated  only  with  restricted  type  units;  the  last  only  with  units  that  have  access  to  the  body  of 
a restricted  type. 


AbstractOps  Is  a list  of  the  units  given  access  to  the  body  of  the  restricted  type. 

Drclaredln  Is  a list  of  the  units  (including  other  type  definitions)  In  which  an 

instance  of  the  restricted  type  is  declared. 


KeferencesFrom  Is  a list  of  the  units  that  reference  the  abstract  object,  Including  units 
In  Drclaredln. 

CheckMappIngFlag  1$  a boolean  flag  that  indicates  whether  the  abstract-concrete  relation 
must  be  checked. 
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CheckSemanticsFlag  and  CheckVCsFlag  are  used  for  both  kinds  of  units  and  have  the  same 
meaning  as  before.  CheckSemanticsFlag  still  has  the  highest  flag  precedence,  subsuming  both 
CheckVCsFlag  and  Check  Mapping!- lag. 

If  the  unit  of  Interest  Is  an  ordinary  type  definition,  this  scenario  still  applies.  A type 
unit  is  a restricted  type  unit  having  only  parts  1 and  i and  with  AbstractOps  set  to  the  union 
of  all  units  that  are  in  Declaredin  and  ReferencesFrom,  since  all  those  units  can  access  its  body. 

Changes  to  Restricted  Types 

1  he  first  five  steps  of  the  following  algorithm  are  concerned  with  determining  the 
global  effects  of  changing  restricted  type  definitions  and  the  sixth  determines  the  local  effects. 

Algorithm  T.  If  a restricted  type  T Is  replaced  by  T’,  the  following  steps  are  performed. 

I.  If  part  I is  changed,  then  set  CheckSemanticsFlag^  for  each  X In 

Declaredin-p. 

2 If  not  SemantlcallyConsistent(T’),  set  Check VCsFIag^  for  each  X In 

ReferencesFrom-j-  and  set  CheckSemanticsFlagy  for  each  Y In 
AbstractOps-j-’,  and  go  to  step  6. 

3 If  part  2 Is  changed  and  IsPathConsistent(Y)  Is  true  for  each  Y called  In  part 
2 of  T and  T’.  then  set  CheckVCsFlagx  for  each  X in  Declaredln-p  If 
Migorlthm  DAG  is  false. 

4.  If  part  9 Is  changed  and  IsPathConsistent(Y)  is  true  for  each  Y called  in 
part  3 of  T and  T’,  then  set  Check VCsFlagx  for  each  X In 
ReferencesFrom-p  if  Algorithm  DAG  is  false. 

5.  If  part  4 is  changed,  set  CheckScmanticsFlagx  for  each  X in  AbstractOps-p*. 

6a  If  not  SemanticallyConsistent(T’),  set  CheckSemanticsFlag-p*. 

6b.  Otherwise,  if  CheckVCsFlag-]  is  not  set  and  part  2 or  3 has  changed  and 
Algorithm  DAL  is  false,  then  set  Check VCsFlag-p*. 

Algorithms  DAG  and  DAL  determine  the  impact  of  changes  to  specIfIcatiPTS,  Just  like 
Algorithms  G and  L in  Section  4.5. 

Step  I ensures  that  all  declaration  sites  are  checked  for  semantic  errors  when  the 
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header  of  T Is  revised  in  T’.  If,  for  example,  T’  takes  a different  number  of  arguments  than  T, 
all  places  where  T was  declared  now  have  a type  mismatch. 

Step  2 determines  the  effects  of  replacing  1 with  a semantically  inconsistent  T’. 
Suppose  that  an  abstract  axiom  of  T is  not  only  changed  in  T’,  but  also  contains  a type  error. 
I'his  error  prevents  the  two  versions  of  the  axioms  from  being  logically  compared.  Therefore, 
all  prcxifs  using  the  axiom  from  1'  are  currently  invalid.  This  is  reflected  in  the  data-base 
structure  by  setting  CheckVCsFlag  for  every  unit  that  declares  or  references  an  instance  of  T. 

Step  2 also  sets  CheckSemanticsFlag  for  each  unit  that  has  access  to  the  internal 
structure  of  T.  A semantic  inconsistency  in  1'’  may  in  turn  cause  all  references  to  its  body  to  be 
inconsistent.  If  this  step  is  executed,  steps  3-5  arc  skipped. 

Steps  3-5  deal  with  changes  to  other  parts  of  restricted  types.  Steps  3-4  isolate  VCs 
affected  by  changes  to  external  specifications.  If  the  body  of  a type  is  revised,  step  5 sees  that 
all  units  accessing  the  internal  structure  of  the  type  are  checked  for  conflicts. 

Locally,  step  6 keeps  instact  proofs  done  for  T that  hold  for  T’. 

One  ex  ception.  It  was  mentioned  at  the  beginning  of  this  section  that  there  is  one 
situation  in  which  the  effects  of  changes  to  types  propagate  like  changes  to  programs.  Consider 
the  following  example: 

lyp*  lyp«l  • r«cord(fieldl:  array  ((I..I0))  of  integer; 

field2:  array  ((I..I0))  of  integer); 

function  f(  ) > 

begin 

exit  tome  xdypel,  . . . x.fieldl  . . . ; 


end; 

type  I is  a record  with  two  fields,  an  instance  of  which  is  declared  in  the  exit  specification  of  f. 
Suppose  that  the  representation  of  typel  is  now  changed  to 

type  lypel  ■ array  ((I..20))  of  integer; 

Notice  the  effect  this  change  has  on  the  exit  specification  of  f.  It  now  contains  a type  error 
because  the  record  notation  "x.fieldl"  is  no  longer  appropriate.  Even  though  callers  of  f may 
not  reference  typel,  their  verification  is  invalidated  if  they  Imported  the  exit  specification  of  f 
for  use  in  proofs. 


Similarly,  Inconsistent  data  type  axioms  can  invalidate  proofs  of  units  that  do  not 
reference  the  type.  In  the  above  example,  the  axioms  for  typel  can  be  used  everywhere  the  exit 
specification  of  f is  used. 


Changes  to  Units  That  Access  Restricted  Types 

These  units  differ  from  ordinary  functions  and  procedures  in  one  significant  way  -- 
some  of  their  specifications  are  used  to  establish  the  needed  abstract-concrete  relationship. 
Algorithm  R,  due  to  the  way  data  abstractions  are  represented  in  the  data  base,  applies  almost 
directly.  The  main  revision  is  that  the  local  part  of  Algorithm  R (step  5)  must  set 
Check  MapplngFlag  whenever  the  abstract-concrete  relation  needs  to  be  reestablished. 

To  resolve  inconsistencies.  Algorithm  R1  must  know  when  to  reset 
Check  MapplngFlag.  After  ensuring  that  a restricted  type  is  semantically  consistent,  step  2a 
resets  it.  Also,  an  additional  step,  either  immediately  before  or  after  step  S,  must  be  added  to 
re.set  CheckMappIngFlag  when  the  operation  "generate  abstract-concrete  VCs"  is  performed. 


Changes  to  Other  Kinds  of  Units 

Data  abstractions  must  be  taken  into  account  when  other  kinds  of  units  change.  This 
mainly  affects  the  function  MarkToCheckVCs,  introduced  In  Section  iA  for  propagating  the 
effects  of  changes  through  the  data-ba.se  structure.  Wherever  It  encounters  a restricted  type 
unit,  it  must  perform  the  same  markings  as  Algorithm  T for  each  affected  part. 
MarkToCheckVCs  must  also  recognize  units  that  access  restricted  types  and  know  when  to  set 
their  CheckMappIngFlag.  Introducing  a data-base  entry  called  CalIsFromMappIngSpecs, 
arialagous  to  CalIsFromExternalSpecs  and  CallsFromlnternalSpecs,  makes  this  recognition 
trivial. 


4.10  Implemenlalion  Notes 

For  use  in  SID,  the  formalization  presented  in  this  chapter  was  altered  ta. 

• Invalidate  only  those  proofs  that  are  actually  (not  Just  potentially)  affected  by 
changes  to  specifications. 

• Allow  for  entry  specifications  to  be  proved  at  all  calling  sites. 
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A<ctually,  more  than  just  an  alteration  to  the  methods  is  needed  to  invalidate  only 
affected  proofs.  Recall  that  this  chapter  assumed  that  specifications  from  called  programs  are 
fully  expanded  during  VC  generation.  And  when  a change  to  a specification  has  effects,  all 
VC.S  containing  that  specification  arc  invalidated. 

But  what  if  the  specification  was  not  actually  used  in  some  of  the  proofs?  SID  does 
npt  invalid^e  them.  Recall  from  Section  3.3  how  SID  adds  specifications  to  VCs.  During  VC 
generation,  only  references  to  specifications  of  called  programs  (instead  of  the  specifications 
themselvesj)  are  added  to  VCs.  Then,  complete  specifications,  or  parts  of  specifications,  that  do 
not  contain  type  errors  are  expanded  as  needed  during  proofs.  Every  expansion  is  recorded  in 
the  data  base.  The  altered  methods  then  use  this  record  to  isolate  those  proofs  that  are  actually 
affected  by  changes  to  specifications.  Often,  only  parts  of  these  affected  proofs  are  invalid. 
SID  therefore  has  additional  mechanisms  for  retaining  still-valid  subproofs. 

A primary  goal  was  to  formulate  the  methodology  in  a general  enough  way  to  enable 
it  to  be  easily  adapted  to  a class  of  Pascal-like  languages  and  their  related  proof  methods. 
Insofar  as  its  adaption  for  use  in  SID,  this  goal  was  realized.  The  main  algorithms  remained 
essentially  intact  with  only  a few  auxiliary  functions  rewritten. 

The  main  adjustments  are  as  follows.  When  changes  to  specifications  affect  proofs, 
MarkToCheckVCs  uses  the  data-base  record  of  where  specifications  were  actually  used  to 
directly  identify  the  affected  proofs.  ExternalSpecCallsTo  additionally  detects  recursive  calls  so 
that  changes  to  headers  will  be  handled  properly.  Before  generating  VCs,  IsPathConslstent 
enrsures  or4y  that  entry  specifications  of  called  programs  are  semantically  consistent 


Page  108 


CHAPTER  5 

DESIGNING  INCREMENTAL  SYSTEMS 


Previous  chapters  illustrated  how  SID  responds  to  changes  and  detailed  the 
methodology  it  empoloys.  I'his  chapter  considers  incremental  systems  in  general,  discussing 
design  considerations,  proposing  a general  framework  for  solving  some  key  design  problems, 
and  Illustrating  some  open  problems. 


5.1  Issues  and  I'radeoffs 

Incremental  systems  respond  to  changes  by  ensuring  that  the  final  problem  solution  is 
consistent  and  by  keeping  intact  as  much  still-valid  work  as  practical.  Both  the  user  and  system 
perspective  on  how  this  happens  is  important.  From  the  user’s  viewpoint,  the  system  keeps 
intact  still-valid  work  without  redoing  previous  work.  In  actuality,  however,  a limited  amount  of 
reprocessing  may  be  desireable. 

I'here  is  a spectrum  of  ways  in  which  individual  components  can  keep  intact  still- 
valid  work.  At  one  end  of  the  spectrum  is  the  most  straightforward  way  to  respond  to  changes 
- simply  redo  everything,  then  ferret  out  what  did  not  need  to  be  redone  by  comparing  new 
results  with  previous  results,  then  bring  to  the  attention  of  the  user  only  work  that  really  needs 
to  be  done.  Although  this  "batch"  approach  conveys  an  incremental  view  to  the  user,  it  is 
often  too  inefficient.  1 he  approach  at  the  other  end  of  the  spectrum  is  to  isolate  the  exact 
impact  of  changes,  and  not  redo  any  still-valid  previous  work.  Since  nothing  is  redone,  the  user 
sees  nothing  being  redone.  1 his  too  can  be  highly  inefficient  since  the  component  may  be 
doing  as  much  work  (or  more)  figuring  out  how  to  keep  from  redoing  work  as  It  would  take  to 
redo  It.  In  short,  the  amount  of  effort  spent  isolating  the  exact  impact  of  changes  is  Inversely 
related  to  the  amount  of  effort  spent  redoing  previous  work. 

What  Is  needed  is  to  adopt  a strategy  that  lies  somewhere  between  these  endpoints. 
1 he  ultimate  goal,  of  course,  is  to  find  a point  at  which  the  total  amount  of  effort  spent 
determining  the  impact  of  changes  and  redoing  previous  work  is  always  minimized.  The  Idea 
here  is  to  localize  the  effects  of  changes  to  a single  unit  of  information  (or  to  a group  of  such 
units),  redo  everything  in  that  locality  when  practical,  then  separate  out  and  show  to  the  user 
only  previous  work  affected  by  the  change.  I'hese  units  of  information  are  pre-defined  and  are 
called  the  grain  of  the  component. 
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Components  also  need  to  be  studied  collectively.  The  main  reasons  are  to  decide  how 
they  Interface  and  how  they  need  to  Interact  to  resolve  inconsistencies.  The  Interface  problem, 
along  with  the  intimately  related  one  of  determining  the  ideal  grain  for  each  component,  Is 
illustrated  by  considering  a partially-ordered  set  of  components  arranged  such  that  component 
A "comes  before"  components  B and  C.  This  ordering  indicates  that  B and  C depend  on  the 
results  of  A (e.g.,  a compiler  and  VC  generator  depend  on  the  results  of  editing  operations). 
The  grains  used  by  B and  C impact  the  kind  of  grain  that  can  be  used  by  A.  The  way  these 
grains  Interrelate  determines  how  easy  it  is  to  Interface  A with  B and  with  C.  Carefully 
choosing  the  grain  of  A so  that  it  is  easy  to  extract  from  its  output  what  B and  C need  to  know 
about  their  grains  makes  the  Interfaces  simple.  Crain  incompatibilities  make  Interfaces  difficult 
If  not  Impractical. 

In  summary,  four  major  interrelated  questions  have  been  raised: 

• How  does  each  component  determine  the  effects  of  changes? 

• How  do  components  Interact  to  resolve  Inconsistencies? 

• What  Is  the  appropriate  grain  for  each  component? 

• How  do  components  fit  together? 

For  answering  the  first  two  questions,  a framework  that  is  general  enough  to  be  adapted  to 
different  kinds  of  systems  by  filling  in  specific  details  as  necessary  Is  proposed  below.  Then, 
the  last  two  open  questions  are  explored. 


5.2  General  Theory 

To  produce  a system  that  automatically  determines  the  effects  of  changes,  the  system 
designer  must  fill  In  the  following  outline  with  task-specific  details.  Each  component  views  Its 
problem  as  being  represented  by  a network  of  nodes,  which  correspond  to  the  grain  of  the 
component,  and  a relation  between  nodes.  1 he  designer  must  define  the  nodes  for  each 
component  (let  node^j  be  an  arbitrary  node  for  component  c)  and  the  relationship  between  them 
(let  usesg  be  the  relation).  Also,  a predicate  is  required  for  deciding  whether  an  externally- 
vlsible  part  of  node^  I uses^  node^.  j (let  UsesInExternalPart((node(.  |,node^  j)  be  this  predicate). 
Chapter  i shows  one  way  to  define  these  items  for  SID.  After  the  details  are  supplied,  the 
algorithm  below  responds  to  changes  by  transforming  the  current  network  to  another  that 
embodies  the  change  and  whatever  else  Is  needed  to  compensate  for  It.  If  node^-i  Is  changed, 
the  necessary  transformations  are  made  by  the  following  steps: 

I.  Determine  IocmI  Impact.  Marknode^j. 


Page  no 


2.  Determine  global  impact.  If  an  cxternally-visible  part  of  rrade^l  Is 
changed,  mark  all  of  Its  users.^  These  users  are  marked  recursively  by: 

MarkUs«rt(nod«^  j)  « 

for  oach  nodo^ j such  that  nodo^ j usot^  nodo^  I 
(mark  nodo^  j; 

if  UsestnExtornalParlf(nodo^  j,nodo^  |)  (hon 
MarkUs«rs(nodO(  j)  ) 

3.  Perform  updating.  Recompute  uses^  relation. 

, 4.  Determine  effects  on  next  component.  If  c Is  not  the  "last" 
component  In  the  system,  repeat  these  steps  for  each  of  the  "next" 
component’s  nodes  that  come  from^^  the  marked  nodes  of  c. 

The  marking  of  a node  Indicates  that  the  associated  component  must  be  (re)applied  to  It.  Next, 
it  will  be  shown  how  these  markings  place  constraints  on  what  can  be  done. 

The  problem  of  resolving  inconsistencies  is  equivalent  to  deciding  when  a component 
can  consistently  be  applied.  Before  applying  component  c to  node^|,  the  following  Is 
performed: 

1.  Start  at  the  beginning.  Trace  node^l  back  to  a node,  or  set  of 
nodes,  for  the  "first"  component. 

2.  Ensure  global  consistency.  Each  traced  node,  from  the  first 
component  to  the  one  immediately  preceding  c In  the  ordering,  must  be 
unmarked. 

S.  Ensure  local  consistency.  If  node^-i  is  marked,  all  paths  from 
node^  I must  be  unmarked. 

In  step  3,  if  node^.  I Is  unmarked,  the  operation  can  be  applied  without  any  local  checking 
because  other  mark^  nodes  cannot  affect  It. 


^ Nodes  that  are  added  (as  opposed  to  changed)  can  be  handled  so  that  they  are  not 
externally  visible,  causing  this  step  to  be  skipped. 

Doing  this  mapping,  which  is  In  general  one-to-many.  Is  part  of  the  grain/interface 

problem. 
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Interestingly,  nodes  are  traced  "backward"  through  the  component  ordering  here  In 
contrast  to  "forward"  as  in  the  other  algorithm.  These  two  requirements  underscore  the 
importance  of  the  grain/interface  problem  and  how  critical  an  efficient  solution  Is. 

Chapter  4 shows  one  way  to  fill  in  the  details  of  these  two  outlines  for  SID.  It  defines 
the  necessary  items  (including  a grain,  a uses  relation,  and  an  "externally-visible"  predicate)  for 
each  individual  component  and  shows  how  to  interleave  them. 


5.3  Future  Research 


Crains  and  Tools 

The  key  observation  to  be  brought  out  is  that  different  tools  typically  have  different 
grains.  Several  different  kinds  of  components  are  considered  and  a possible  grain  for  each  is 
suggested.  Even  though  components  are  discussed  separately,  remember  that  they  must  be 
viewed  collectively  when  designing  a system. 

VC  generator.  Suppose  this  component  works  by  first  dividing  a program  into  paths, 
then  generating  VCs  for  each  path.  Whenever  a program  Is  changed,  it  needs  to  know  if  any 
new  VCs  need  to  be  generated.  In  particular,  it  needs  to  know  what  paths,  rather  than  what 
syntactic  constructs  (like  expressions  or  statements)  within  paths,  are  changed.  Hence,  a 
convenient  grain  is  a program  path. 

Optimiting  compiler.  When  compiling  a for-loop  of  the  form 


for  i from  I io  n do 
x«-k*n; 

the  statement  "x«-k<»n"  is  properly  optimised  out  of  the  loop.  If,  for  example,  the  "n”  in  this 
statement  is  changed  to  an  "l”,  the  compiler  is  not  so  concerned  about  knowing  that  "n"  is  now 
"i",  but  about  knowing  that  it  needs  to  recompile  the  whole  for-loop.  Thus,  an  optimized  unit  is 
an  obvious  grain  for  this  component.  An  example  of  an  Incremental  compiling  scheme  is  in 
Mitchell  [701 

Fditor.  A useful  grain  for  an  editor  is  an  operation.  Having  this  as  the  actual  grain 
enables  it  to  have  three  logical  grains  - an  operation,  a sequence  of  operations,  and  an  editing 
session.  For  example,  all  these  are  useful  for  providing  a flexible  do-undo  feature  that  reflects 
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boih  program  development  and  verification  concerns.  INTERLISP  iTeltelman  75]  uses  this 
feature  effectively  for  program  development. 

FquIvMlence-preserving  transformer.  This  component  takes  an  abstract 
program  and  converts  It  into  a more  concrete  one  by  successive  transformations.  These 
transformations  are  selected  by  the  programmer,  then  applied  automatically.  Since 
transformations  are  equivalence-preserving,  the  program  produced  Is  guaranteed  to  be  a valid 
implementation  of  the  abstract  program.  Such  schemes  (e  g.,  Balzer,  et  al.  [76],  Gerhart  [75], 
and  Standish  [76])  typically  operate  on  program  segments. 

As  a simple  example  of  what  an  incremental  transformer  does,  consider  the  following 
sequence  of  statements: 

for  i from  I lo  n do  B[il«-i*l; 
for  j from  I to  n do  C[j]«-B[j]*D[j]; 

These  two  for-loops  can  be  combined  into  a single  one,  viz., 

for  i from  1 to  n do 

begin  B(i]*-i»l;  C[i]*-B[i]»D[i]  end; 

The  transformer  must,  however,  account  for  the  fact  that  a change  to  the  original  segment 
may  invalidate  this  transformation.  Thus,  it  needs  to  keep  program  segment-transformed 
segment  pairs,  making  it  convenient  to  deal  with  changes  at  the  segment  level. 


Fitting  the  Pieces  Together 

Interfacing  a set  of  components  requires  establishing  a partial  ordering  of  components 
and  being  able  to  map  between  nodes  of  different  components.  The  latter  is  particularly 
difficult. 

One  of  the  key  decisions  is  deciding  how  changes  will  be  introduced  into  the  system. 
T o isolate  exact  changes,  an  editor  is  required  as  the  "first"  component  in  the  system.  The 
reason  for  this  requirement  is  that  the  alternative  of  using  a "pattern  match"  approach,  while 
effective  In  some  situations  (as  shown  in  SID),  is  highly  unsatisfactory  in  isolating  exact 
changes.  It  may  require  excessive  processing  to  isolate  exact  changes  (e.g.,  equivalence- 
preserving  operations  like  uniformly  renaming  a variable  are  difficult  to  Identify)  in  part 
because  the  sequence  of  editing  operations  is  lost. 

I'he  ideal  editor  not  only  executes  commands,  but  also  is  aware  of  the  context  in 
which  they  are  executed.  The  Impact  of  executing  an  editorial  command  is  determined  by 
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mapping  the  editor’s  context  to  the  •’equivalent-  context  for  other  components.  This  Is  done  by 
one  of  the  algorithms  In  Section  5.2. 

Arriving  at  specific  guidelines  for  designing  these  mappings,  as  well  as  for  choosing 
grains,  are  Important  areas  for  future  research. 
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